Hunting IDOR Vulnerabilities with Burp Suite: A $1,000 Bug Bounty Case Study

Disclaimer:
This post is for educational and defensive purposes only.
The case discussed here was originally discovered by another independent security researcher.
Our goal is to analyze it technically and ethically so developers and security professionals can learn how to detect, prevent, and fix similar flaws.

Introduction

In modern web applications, one small oversight in access control can lead to massive data exposure. Among the most common - yet underestimated - flaws is IDOR (Insecure Direct Object Reference).
Despite its simplicity, IDOR remains one of the top causes of real-world data breaches and continues to yield four-figure rewards in bug bounty programs.

In today’s case study, we’ll explore a $1,000 IDOR vulnerability that was uncovered and responsibly disclosed by a security researcher in early 2024.
Rather than simply telling the story, this post will teach you the underlying techniques, Burp Suite workflows, and developer-side defenses that make or break security around direct object access.

What Is an IDOR Vulnerability?

IDOR (Insecure Direct Object Reference) occurs when a web application exposes a direct reference to internal objects (like files, database records, or account IDs) without verifying that the requester is authorized to access them.

Imagine you’re visiting your profile on a shopping website:

https://shop.example.com/profile?id=1001

If changing that id value to 1002 lets you see another user’s profile, you’ve just discovered an IDOR vulnerability.

At its core, IDOR is a broken access control flaw - an attacker manipulates an identifier or parameter (object reference) to gain access to someone else’s data.

🧠 Quick Analogy

Think of it as a hotel with room keys numbered sequentially.
If Room 101’s guest can also open Room 102 because the locks aren’t properly assigned, you’ve got an IDOR in real life.

Types of Access Control Issues

1. Horizontal Privilege Escalation – Accessing another user’s data at the same level.
   Example: Customer A views Customer B’s invoice by guessing the invoice ID.
2. Vertical Privilege Escalation – Accessing administrative or higher-privilege functions.
   Example: A regular user accesses /admin/settings by modifying a URL or role field.
3. Indirect References – Even if IDs are hashed or obfuscated (e.g., Base64, UUIDs), IDORs can still occur when the backend doesn’t enforce ownership checks.

Why IDORs Still Exist in 2025

Despite awareness, IDORs persist due to a dangerous assumption:

“If users can’t see another user’s ID, they can’t access their data.”

Developers often rely on client-side trust or opaque IDs without binding them to authenticated users.
But security isn’t about hiding - it’s about validating.

In an era of microservices, API-first apps, and mobile clients, IDORs are more likely to slip through because backend endpoints are reused across contexts.

Deep Dive: Understanding IDOR in Modern APIs

Modern web applications heavily rely on APIs, where user identifiers and object references are exchanged constantly.
These may appear as JSON bodies, headers, or even hidden fields - not just query parameters.

Consider a RESTful endpoint:

GET /api/orders/3245
Authorization: Bearer eyJhbGciOiJIUzI1...

If the server doesn’t verify that the user_id in the JWT corresponds to the order’s owner, the attacker can simply change the order ID and view someone else’s order.

Or imagine a GraphQL query:

{
  getUser(id: "1234") {
    name
    email
    orders {
      id
      total
    }
  }
}

If backend resolvers don’t check ownership, even GraphQL can leak data via IDOR.
APIs built with frameworks like Django REST, Express, or Laravel are all vulnerable when developers skip permission_classes or custom access checks.

The Researcher’s Setup: Why Burp Suite Is Key

Burp Suite, developed by PortSwigger, is the most versatile web security testing platform available - and it’s the same company behind PortSwigger Web Security Academy.

🎯 Why Burp Suite Works Perfectly for IDOR Testing

• Proxy intercepts and logs all HTTP/S requests.
• Repeater allows manual replay and modification.
• Intruder automates bulk parameter fuzzing (e.g., ID ranges).
• Comparer helps identify differences in responses.
• Extensions like Autorize, AuthMatrix, and AutoRepeater simplify authorization testing.

These features make Burp the Swiss Army knife for ethical hackers.
It’s not about exploiting - it’s about understanding how the system handles identity.

Step-by-Step: Finding an IDOR with Burp Suite

Let’s break down the full process in a way that beginners can replicate ethically on legal targets.

1️⃣ Setup Burp & Browser

• Launch Burp Suite (Community or Pro).
• Go to Proxy → Options and ensure listener is on 127.0.0.1:8080.
• In your browser (Firefox or Chrome), install FoxyProxy and set your proxy to Burp.
• Export and install Burp’s CA certificate for HTTPS interception.

2️⃣ Browse Normally and Capture Traffic

Open your target website (in scope).
Burp’s HTTP history will fill with requests like:

GET /user/profile?id=123 HTTP/1.1
Host: example.com

Right-click any interesting request and Send to Repeater.

3️⃣ Tamper in Repeater

Now edit the ID or parameter. Example:

GET /user/profile?id=124 HTTP/1.1

Click Send.
If the response shows different user data, congratulations - you’ve found an IDOR vulnerability.

4️⃣ Automate with Intruder

To test larger ranges:

• Right-click → “Send to Intruder”.
• Add § markers around the vulnerable ID.
• Choose “Sniper” or “Cluster Bomb” attack type.
• Load sequential numbers as payloads.
• Start attack and sort results by response length or status code.

A different size or HTTP 200 where others are 403s = possible valid data leak.

5️⃣ Validate the Finding

Always confirm responsibly:

• Check if data truly belongs to another user.
• Avoid mass exploitation.
• Document clear evidence (e.g., user ID mismatch, response differences).

The $1,000 Bug Bounty Case: Real-World Walkthrough

In early 2024, a security researcher discovered an IDOR in an e-commerce platform’s order API.
Here’s how it unfolded - simplified for educational clarity.

1️⃣ Discovery Phase

While browsing order history, the researcher noticed requests like:

GET /api/orders?order_id=56789

By modifying the value to 56790, the server returned another customer’s entire order JSON:

{
  "order_id": 56790,
  "name": "John Doe",
  "email": "john@example.com",
  "shipping_address": "California, USA",
  "items": [...],
  "payment_partial": "****4321"
}

This confirmed unauthorized horizontal access - an IDOR.

2️⃣ Validation Phase

The researcher then automated enumeration via Burp Intruder, testing sequential order IDs (56,700–57,000).
Response lengths varied, meaning different valid records existed.

Within minutes, dozens of real users’ order details were visible - proving lack of object-level authorization.

3️⃣ Reporting & Responsible Disclosure

A professional, detailed report was submitted:

• Steps to reproduce
• Screenshots of requests/responses
• Proof-of-concept video
• Suggested remediation (server-side checks)

The vendor triaged it as medium severity and awarded $1,000 for the responsible disclosure.

Developer Breakdown: How to Prevent IDOR

Developers often assume “unique IDs” mean “secure IDs.”
Let’s fix that mindset.

✅ 1. Enforce Authorization on Every Request

Server-side logic should verify ownership like this:

SELECT * FROM orders
WHERE id = :requested_id
AND user_id = :current_user_id;

If no match → return a generic 404 or 403 without revealing existence.

✅ 2. Use Indirect or Signed References

Instead of exposing raw IDs:

# Insecure
GET /api/order?id=123

# Secure
GET /api/order?ref=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Use short-lived tokens or signed URLs.

✅ 3. Minimize Data Exposure

Return only required fields.
Avoid sending emails, full addresses, or internal IDs unless necessary.

✅ 4. Implement Role-Based Access Control (RBAC)

Ensure only the rightful owner or authorized roles can access resources.
Apply least privilege for every endpoint and user role.

✅ 5. Add Logging & Rate Limiting

Monitor repeated requests with incremental IDs (pattern: id=100,101,102,...).
Add alerts in SIEM tools for enumeration attempts.

Real-World Examples of IDOR Gone Wrong

1. Facebook 2019 Bug – Allowed attackers to view private photos of users due to IDOR in album endpoints.
2. Capital One 2019 Breach – Misconfigured access policies led to exposure of 100M+ records.
3. GitLab 2021 – API endpoints exposed private project data via predictable identifiers.
4. Tesla Bug Bounty 2022 – IDOR in vehicle API allowed viewing other owners’ VIN data - paid $10,000 bounty.

Each incident reinforces one truth:

Broken access control isn’t just an oversight - it’s an open door.

For Bug Hunters: Crafting Professional Reports

Here’s a quick checklist for your next IDOR report:

Common Pitfalls While Testing

Defensive Perspective: Secure Coding Against IDOR

Security isn’t a one-time patch - it’s culture.
Here’s what developers can do proactively:

• Validate ownership in middleware (e.g., Express.js middleware, Django DRF permissions).
• Use centralized access control frameworks like Casbin, Keycloak, or Auth0 Rules.
• Redact internal references from client-side code.
• Run automated access-control tests in CI/CD.
• Conduct regular penetration testing and peer code reviews.

Developer vs. Hunter Mindset

Together, these three roles form a strong defense loop - the same loop that makes the internet safer.

Final Thoughts

The $1,000 IDOR bug wasn’t about a clever payload - it was about curiosity, observation, and responsible testing.

Access control vulnerabilities like IDORs remind us that security is a process, not a product.
Every time a researcher finds and reports one, the web becomes a little safer.

If you’re just starting your journey:

• Practice on PortSwigger Web Security Academy.
• Join HackerOne or Bugcrowd.
• Always report ethically and responsibly.

Your first $100 bug could be the start of a long, rewarding career.

References

• OWASP: Broken Access Control (A01:2021)
• PortSwigger Web Security Academy – IDOR Labs
• HackerOne Reports Archive
• CWE-639: Authorization Bypass Through User-Controlled Key

Published on herish.me - Building the most beginner-friendly, trustworthy cybersecurity knowledge hub.