Recently, I was hunting on a target that I can’t disclose because of its responsible disclosure program, even though it’s public. While exploring one of its subdomains, I started analyzing the application more closely. During this process, I came across IDOR vulnerability that eventually earned me a $3000 bounty.
What is IDOR vulnerability? #
IDOR stands for Insecure Direct Object Reference. It’s a type of access control vulnerability where an application exposes a reference to an internal object, like a user ID, order ID, or document number, without properly checking if the logged-in user is allowed to access it. In simple terms, it means that by changing a value in the request, such as replacing your own user ID with someone else’s, you might be able to see or modify data that doesn’t belong to you and in some cases also perform unauthorized action.
Initial Analysis #
When I discovered the subdomain, my first step was to explore and understand all the functionality of the application. The app turned out to be a delivery service platform where business owners can send parcels or add drivers to deliver them across different locations. Since there were many endpoints, I decided not to jump straight into testing. Instead, I focused on mapping the application and learning what each endpoint was meant to do.
To do this, I turned on BurpSuite and started clicking around in the UI, performing different actions while capturing the requests. While going through them, I noticed that several endpoints were using numerical IDs. This immediately made me think of testing for IDOR. To confirm, I created two accounts (let’s call them TestA and TestB) and started testing.
The Endpoint That Broke Access Control #
While exploring the application, I came across a functionality that allowed an admin to add a driver application. This driver application was essentially a document that contained sensitive details such as the driver’s name, email, vehicle number, driver ID, and government-issued ID numbers. On top of that, the user was also required to upload images of uploading documents like a driving license, identity proof, and proof of address etc. In short, this single document stored a lot of personal and sensitive information about drivers.
When I clicked on Submit, the application generated a PUT request that contained the driver ID in the URL. This immediately caught my attention. To test it, I sent the request to Burp Repeater with User A session and replace the cookies with User B session. So basically now i’m trying to access data from different user’s session.
The result was surprising. Not only was I able to access the data of User A, but the driver application (which belonged to User A account) also got linked to User B’s account. This meant I could fetch any driver’s application by simply changing the ID in the request. Since the application contained sensitive details along with uploaded ID images, all of this information became directly visible in the browser.
Here’s the first IDOR worth $1500, now let’s talk about the second one.
Similar to the driver application endpoint, I also came across another endpoint responsible for adding a vehicle application. This feature was designed to store documents related to a vehicle that would be used by drivers. The vehicle application contained details such as the user’s name, email, phone number, and other related information. It also required uploading sensitive documents like the vehicle license ID, insurance papers, and roadworthy certificates. Once again, the request URL contained an ID parameter, which immediately raised the possibility of an IDOR vulnerability.
I repeated the same steps I used on the driver application endpoint and tested this one by modifying the ID parameter. The results were the same, I was able to view all the sensitive details of the victim’s vehicle application. On top of that, I could perform an unauthorized action where the vehicle application belonging to User A was linked to the attacker’s account (User B). As a side effect, the application was also removed from User A’s account. This meant an attacker could not only steal sensitive vehicle data and documents but also effectively link with and delete another user’s application.
Why the Vulnerability Is Critical: Impact #
This vulnerability had a serious impact because it exposed highly sensitive personal and financial information. An attacker could view and download private documents such as government IDs, driving licenses, proof of address, vehicle licenses, and insurance certificates. Beyond just data exposure, the flaw also allowed unauthorized actions like linking or removing driver and vehicle applications from other users’ accounts. This meant an attacker could not only steal personal data but also tamper with or delete legitimate applications, leading to identity theft, fraud, and potential disruption of business operations. In short, the vulnerability posed both privacy and security risks, making it critical severity.
Responsible Disclosure: Reporting the Bug #
After confirming the vulnerability and gathering enough evidence, I prepared a detailed report for the program. In the report, I explained the issue step by step, starting with how I discovered the vulnerable endpoints, the test accounts I used, and the exact requests and responses that proved the IDOR. I also highlighted the sensitive nature of the exposed data, including personal IDs, driving licenses, and vehicle documents, and explained how an attacker could exploit this to steal information or tamper with user accounts. To make it clear, I added lots of screenshots and PoC requests so the triage team could easily reproduce the issue.
Within a short time, the program acknowledged the report, confirmed the impact, and marked it as high severity. Eventually, it was rewarded with a $3000 bounty in total, $1500 for each IDOR bug!
This bounty felt really special to me because I hadn’t been hunting for very long, and $3000 is a big number for me. When I got the notification, I was genuinely happy, it gave me a lot of motivation to keep learning and pushing further in bug bounty.
I also create bug bounty–related videos on my YouTube channel, and in one of them I talk about how to approach IDOR vulnerabilities step by step. If you’re interested in learning more, you can check it out from the link above.
Thank you so much for reading!