(IDOR)Allows Deletion of OpenAPI Specification Files Across Organizations

Hello,

Today, I will talk about how I discovered a Cross-Tenant IDOR that allowed deleting any OpenAPI Specification file without having any relationship with the victim organization. I will refer to the website as Target because the vulnerability has not been resolved yet.

The application provides Application Performance Monitoring , which allows companies to monitor the performance of their web applications.

While exploring the application and understanding how it works, I noticed that it uses a GraphQL API. I also observed that the application hides certain features using a parameter such as

"value": false

"value": false

So I thought, what if I use Burp Suite's Match & Replace to change this value to true?

It worked, and the hidden feature appeared.

Then I wanted to check whether I could actually use this feature or if there was any server-side validation. I investigated the API and found that it allows users to upload .yaml files, which are used to define an OpenAPI Specification containing API endpoints, requests, responses, and more.

After creating an API Specification, I asked myself:

Can I edit or delete this file if I don't belong to the organization?

To test this, I created a second account (Attacker) and created another API Specification. I first tested whether I could enumerate or edit the victim's API Specifications, but I couldn't find anything interesting, as the backend appeared to enforce authorization correctly. then moved on to testing the delete functionality and intercepted the delete request.

While analyzing the request, I noticed a parameter called contractId. The API Specification ID was Base64-encoded and looked like this:

ODAwMjczOXxOR0VQfFJFU1RfQVBJX0NPTlRSQUNUfDAxOWVmZGYyLTZjYjEtN2IwNy1iMTI3LTAyOTdlMjhjZTNjZg

ODAwMjczOXxOR0VQfFJFU1RfQVBJX0NPTlRSQUNUfDAxOWVmZGYyLTZjYjEtN2IwNy1iMTI3LTAyOTdlMjhjZTNjZg

After decoding it, I found that it contained:

accountId | NXXP | REST_API_CONTRACT | GUID

accountId | NXXP | REST_API_CONTRACT | GUID

My first idea was to change only the GUID to see whether the backend validated that the GUID actually belonged to the specified account.

I changed only the GUID and tried to delete the resource, but the request was rejected with Access Denied.

Then I wondered:

What would happen if I changed both the accountId and the GUID to the victim's values?

I modified both values and resent the request.

This time, the request succeeded.

The victim's OpenAPI Specification was deleted successfully, even though my account had no relationship with the victim organization and no roles within it.

Based on my testing, it appears that the backend validates the relationship between the accountId and the GUID, but does not verify whether the authenticated user is actually authorized to access that account

Steps to Reproduce

1. Create two accounts:

• Account A (Attacker)
• Account B (Victim)

2. In the victim organization, create an API Specification.

3. In the attacker organization, create another API Specification.

4. Capture the delete request for the attacker's API Specification.

5. Replace the contractId with the victim's contractId.

6. Send the request.

7. Observe that the API Specification belonging to Organization B is deleted successfully

The victim's GUID can be enumerated in certain scenarios. For example, if you were previously a member of the victim's organization and later left it, you may still be able to obtain the required GUID.

Impact

An attacker can:

• Disrupt API documentation and development workflows.
• Affect multiple customers in a multi-tenant environment.

This issue represents a Cross-Tenant Authorization Bypass that compromises the integrity of organizational resources

Conclusion

When analyzing requests, if you find a feature controlled by a parameter set to false (disabled). First, try techniques like Match and Replace to understand how the feature works and whether enabling it exposes additional functionality.

Sometimes, a seemingly low-impact finding can lead to much more impactful vulnerabilities. Always take the time to explore the feature and dive deeper before reporting it.