Hunting for IDORs: How I Accessed PII on a Popular Ticketing Site!

Hunting for IDORs: How I Accessed PII on a Popular Ticketing Site! | by Vanshrathore - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original Hunting for IDORs: How I Accessed PII on a Popular Ticketing Site! Vanshrathore Follow ~4 min read · April 2, 2026 (Updated: April 2, 2026) · Free: Yes Hunting for IDORs: How I Accessed PII on a Popular Ticketing Site! Between navigating computer science coursework and hands-on cybersecurity practice, I spend a lot of time analyzing web traffic and hunting for logical flaws. Recently, during a bug bounty session, I discovered a high-severity Insecure Direct Object Reference (IDOR)—also known as Broken Object Level Authorization (BOLA)—on a major travel booking platform. ​While the bug ultimately turned out to be an internal duplicate, the process of finding and exploiting it was a textbook example of why access control checks are critical. Here is a breakdown of how I uncovered the vulnerability and the tools I used to build the Proof of Concept (PoC). ​The Reconnaissance Phase ​The target was a widely used platform for booking flights, trains, and buses. My methodology usually involves mapping out the core functionalities as an authenticated user first, keeping a close eye on how the application handles API requests for data retrieval. ​I navigated to the section of my account that logs failed ticket bookings. To see what was happening under the hood, I routed my browser traffic through a proxy and clicked to view the details of one of my failed transactions. ​Spotting the Vulnerability ​Checking the HTTP History, I noticed a standard GET request fetching the booking details. The request relied on a specific trip identifier passed as a parameter (e.g., trip-id=[REDACTED]). ​This behavior immediately raised a red flag. The application appeared to be relying solely on this user-supplied identifier without adequately verifying if the authenticated session token actually owned that specific resource. If the backend simply parsed the ID and returned the database entry without an authorization check, it would be vulnerable to IDOR. ​Tools of the Trade ​To validate and document this finding, I relied on a straightforward but effective tech stack: ​Burp Suite (Proxy & HTTP History): Essential for intercepting the initial request and identifying the vulnerable GET endpoint and its parameters. ​Burp Suite (Repeater): Used to manually modify the trip-id parameter and verify that the server returned a 200 OK status with data, confirming the lack of authorization checks. ​Burp Suite (Intruder): Used to automate the exploitation phase. I targeted the last four digits of the booking identifier and fuzzed the parameter to demonstrate the scale of the exposure. ​ChatGPT: The API response returned a massive, unformatted JSON blob containing the exposed user data. To make my PoC clear and undeniable for the triage team, I used ChatGPT to instantly parse the raw JSON and represent the victim's data (like PNRs, ticket prices, and contact info) in a clean, labeled summary. ​The Exploitation (Proof of Concept) ​With my tools set up, I sent the intercepted request to Burp's Intruder tab. Instead of guessing entirely random strings, I selected the last four digits of the booking ID (e.g., 4697) and ran a payload attack utilizing a range of numbers. ​The results were immediate: multiple payloads (such as 5206, 2949, and 4588) returned an HTTP 200 OK status code. By examining the JSON responses of these successful requests, I found that I was able to access the full ticket information of other users on the platform—including those who had successfully completed their bookings. ​The Impact ​The severity of this vulnerability was critical. By simply enumerating the booking IDs, an attacker could programmatically scrape a massive amount of sensitive user data, including: ​Full passenger names and dates of birth. ​Detailed travel itineraries, PNRs, and E-Ticket numbers ​Fare breakdowns and payment gateway details ​Contact information (emails and phone numbers) ​This kind of exposure poses a massive privacy violation, violates data protection regulations, and opens the door for targeted social engineering or phishing attacks. ​Mitigation Strategies ​To prevent this type of vulnerability, platforms handling sensitive user data must enforce robust access controls. I recommended the following mitigations in my report: ​Enforce Server-Side Authorization Checks: Always validate that the authenticated user actually owns or has explicit permission to access the requested resource before querying the database. ​Avoid Direct References: Replace sequential or predictable IDs with indirect references or securely mapped UUIDs. ​Secure Session Authorization: Ensure that sensitive data is fetched based on the logged-in user's session token, rather than blindly trusting a client-side request parameter. ​The Outcome ​I responsibly disclosed my findings, including a detailed write-up and a video PoC, to the company's security team. They responded promptly, acknowledging the validity of the bug. However, they informed me that the issue had already been identified internally and was currently being tracked alongside other related findings. ​While it was marked as a duplicate and didn't result in a bounty this time, finding a critical IDOR in a production environment of this scale is always a rewarding experience. It's a great reminder to never assume that an application is verifying your permissions just because you are logged in. #bug-bounty #ethical-hacking #pentesting #hacking #money Reporting a Problem Sometimes we have problems displaying some Medium posts. If you have a problem that some images aren't loading - try using VPN. Probably you have problem with access to Medium CDN (or fucking Cloudflare's bot detection algorithms are blocking you).