Crossing the Boundary: How a Simple IDOR Allowed Me to Upload Files to Any Organization

Introduction

During a recent bug bounty hunt on a popular B2B management platform, I was testing a feature that allows organizations to create and manage internal "standards." Everything seemed secure on the surface, but by digging a little deeper into how the platform handled file uploads, I discovered a critical Broken Access Control flaw. This vulnerability allowed an attacker to completely cross tenant boundaries and upload potentially malicious files directly into the private workspaces of any other organization on the platform.

The Reconnaissance / Observation

I started by exploring the application's "Standards" module as a regular user. The workflow was straightforward: you create a new standard for your organization, and then you can attach relevant files or documents to it.

While monitoring the HTTP traffic in Burp Suite, I noticed that when I created a standard, it was assigned a unique identifier (ID) in the URL (e.g., https://[REDACTED].com/standards/<STANDARD_ID>). Later, when I uploaded a file to this standard, the application sent an API request that included this exact standard_id inside the request body.

My hacker sense immediately started tingling. The application was asking my browser where the file should go. I asked myself the golden question of access control testing: What happens if I tell the server to upload my file to an ID that belongs to a completely different company?

The Vulnerability

This flaw is a textbook example of an Insecure Direct Object Reference (IDOR), which is a type of Broken Access Control.

In a secure system, when a user tries to modify a record (like uploading a file to a standard), the server should first ask: "Does the user making this request actually belong to the organization that owns this standard?"

In this case, the server skipped that vital check. It blindly trusted the standard_id provided in the request body. It assumed that because I was logged in, I was allowed to interact with whichever standard ID I threw at it.

The Exploitation

To exploit this vulnerability, I only needed one piece of information: the target organization's standard ID. Since these IDs can sometimes be leaked via web archives (like the Wayback Machine), OSINT, or even basic enumeration, finding one is highly plausible.

Here is exactly how I executed the attack:

1. Target Acquisition: First, I simulated the victim organization by creating a standard in a separate account and copying its ID from the URL. (In a real attack, the hacker grabs this ID from external sources).

1. The Setup: I logged into my attacker account and created my own valid standard in my own workspace.
2. Intercept the Upload: I initiated a file upload to my own standard, but before the request could leave my browser, I intercepted it using Burp Suite.
3. The Swap: In the intercepted POST request body, I located the standard_id parameter. I deleted my own ID and pasted in the victim organization's ID.

1. The Execution: I forwarded the modified request to the server.
2. The Result: The server returned a 200 OK success message. When I checked the victim organization's account, my file was sitting right there inside their private standard overview.

The Impact

The impact of this vulnerability is severe. By exploiting this IDOR, a malicious actor could upload infected files — such as malware, ransomware, or malicious macros embedded in PDFs and Office documents — directly into the trusted internal environment of another company. When employees of the victim organization open these "standard" documents expecting legitimate company policies, they would be compromised. Furthermore, an attacker could overwrite legitimate documents with false information, severely disrupting the target organization's business operations.