Deleting Any Organization’s Workflows via GraphQL IDOR

Introduction

During a recent bug bounty hunt on a prominent B2B SaaS platform, I discovered a critical vulnerability that represents the ultimate nightmare for any cloud service provider: a cross-tenant data destruction flaw. By chaining a simple information disclosure bug with a Broken Access Control flaw in the platform's GraphQL API, I was able to reach across tenant boundaries and permanently delete critical business workflows belonging to any other organization on the platform.

The Reconnaissance / Observation

The target application allows organizations to create internal policies called "Standards." Within these Standards, organizations can configure complex "Workflows" to automate their business logic.

While testing the application, I monitored the background API traffic in Burp Suite to see how the frontend communicated with the backend. I noticed that everything was powered by GraphQL. When I opened a Standard to view it, the app sent a GetStandardVersion GraphQL query containing the Standard-id to fetch the page's data. Later, when I deleted a workflow, the app sent a different GraphQL mutation containing a specific Workflow-id.

I started to wonder: The platform uses IDs to fetch and delete items, but does the backend actually verify who owns those IDs?

The Vulnerability

This attack relied on a severe Insecure Direct Object Reference (IDOR) vulnerability, which occurred in two distinct phases:

1. Information Disclosure: The GetStandardVersion GraphQL query did not check if the requesting user belonged to the organization that owned the Standard-id.
2. Destructive IDOR: The workflow deletion mutation did not verify if the user attempting to delete a Workflow-id actually had the rights to do so.

Because the backend blindly trusted the IDs provided in the API requests without enforcing tenant isolation, a user from Organization A could read and destroy data belonging to Organization B.

The Exploitation

To exploit this vulnerability, I chained the two flaws together. Here is exactly how the attack unfolded:

1. The Setup: I logged into my attacker account and created my own Standard with a dummy workflow, just so I could interact with the platform's features.
2. Finding the Target: I needed a victim's Standard-id. Because these IDs are often included in public-facing URLs (e.g., https://[REDACTED].com/standards/<ID>), they frequently leak into web archives or can be found through basic OSINT. I grabbed a valid ID belonging to another organization.
3. Leaking the Internal Data: In Burp Suite, I intercepted a GetStandardVersion GraphQL request and swapped my own Standard-id with the victim's Standard-id. The server happily responded with all the hidden details of the victim's standard—most importantly, leaking all of their internal Workflow-ids.

4. Preparing the Strike: Next, I went to my own standard in the browser and clicked the "X" button to delete my dummy workflow. I intercepted this deletion request before it left my computer.

5. The Execution: Inside the intercepted GraphQL request body, I found the id parameter pointing to my dummy workflow. I deleted my ID, pasted in the victim's Workflow-id that I had just leaked, and forwarded the request to the server.

6. The Result: The server processed the request successfully. The victim organization's workflow was instantly and permanently deleted.

The Impact

The real-world consequences of this vulnerability are catastrophic.

• Permanent Data Loss: An attacker could script this process to mass-delete workflows across the entire platform, permanently destroying the critical business logic and configurations that victim organizations rely on.
• Severe Reputational Damage: For a SaaS provider, tenant isolation is the foundation of customer trust. A cross-tenant attack — where one customer can reach into the private workspace of another and destroy data — is the most damaging scenario possible, potentially leading to massive loss of trust and legal liabilities.