IDOR Vulnerability: 15-Step Burp Lab Walkthrough Guide

🔒 What an IDOR vulnerability is (in plain, practical terms)

An IDOR vulnerability happens when an app lets you access an object (profile, invoice, order, file, API record) by referencing it directly, and the server doesn't properly verify you're allowed to access that object. In other words, the app trusts "the ID you asked for" more than "who you are."

PortSwigger describes IDORs as a subcategory of access control issues where user-supplied input directly references objects, and attackers can modify that reference to access other objects without authorization. (PortSwigger)

🧭 IDOR vulnerability testing rules (scope, safety, and sanity)

Only test systems you own or have explicit permission to test. Bug bounty programs publish scope and rules because testing without permission can create legal and operational problems fast.

Before you start IDOR vulnerability testing, set up:

• Two test users (User A + User B) in the same scope.
• A clear list of "allowed actions" (browsing, editing, fuzzing).
• A rate limit plan (don't melt the target with automation).
• A note template for endpoints, IDs, and results.

If you want a structured testing mindset, NIST's testing and assessment guide emphasizes planning, executing safely, then documenting findings and mitigation steps. (NIST Computer Security Resource Center)

🧰 Burp Suite setup for IDOR vulnerability testing (the real checklist)

If your proxy setup is sloppy, your results will be sloppy. Start by verifying Burp's proxy listener.

PortSwigger's Burp documentation notes that Burp creates a default proxy listener on 127.0.0.1:8080 and you should confirm it's active before configuring your browser. (PortSwigger)

Here's the clean setup flow:

• Confirm the proxy listener is running (default 127.0.0.1:8080). (PortSwigger)
• Decide: Burp's built-in browser or your own browser.
• Install Burp's CA certificate for HTTPS interception (otherwise you'll fight TLS warnings all day).
• Keep Intercept off until you actually need it (you want control, not chaos).

🌐 Burp built-in browser vs external browser (pick your weapon)

Burp's built-in browser is usually the easiest start because it's designed to work with Burp's proxy defaults. PortSwigger explains the default listener supports using Burp's browser to test browser-based apps. (PortSwigger)

An external browser is also fine, but it adds moving parts. If you do external, PortSwigger's Chrome configuration guide shows using 127.0.0.1 and port 8080 for the proxy settings. (PortSwigger)

Practical advice:

• Use built-in browser for labs and quick workflows.
• Use external browser if you need your normal extensions, profiles, or logins.

🎯 Capture the baseline request for IDOR vulnerability testing

Every IDOR vulnerability test starts with a baseline request that works for your user. If you don't have a working baseline, you're not testing IDOR—you're guessing.

Look for endpoints like:

• /my-account?id=wiener
• /api/users/123/profile
• /orders/8892
• /download?file=1029.pdf

PortSwigger's access control labs commonly highlight user-controlled identifiers on account pages, which is exactly what you should hunt for. (PortSwigger)

🧾 Spot object references (IDs) hiding in plain sight

An IDOR vulnerability usually sits in one of these places:

• URL path: /api/users/12345/profile
• Query parameter: /my-account?id=wiener
• Request body:
• Headers: X-User-ID: 12345
• Cookies (less common, but it happens)
• GraphQL variables (very common now)

Your job is to find where the server uses the reference to fetch data, then verify the server enforces authorization for the fetch.

🔁 Repeater workflow for IDOR vulnerability testing (small changes, big truth)

Repeater is where you prove the bug cleanly. The method is boring, which is why it works.

Rules for Repeater:

• Change one thing at a time (the ID).
• Keep the same session/token.
• Compare responses carefully (status code, body fields, behavior).

Here's a safe demo pattern (for labs / authorized apps):

GET /my-account?id=wiener HTTP/1.1
Host: .web-security-academy.net
Cookie: session=...

Then try:

GET /my-account?id=carlos HTTP/1.1
Host: .web-security-academy.net
Cookie: session=...

PortSwigger literally teaches this flow in their own "Testing for IDORs" workflow, using a Web Security Academy lab as the example and sending the request to Intruder/Repeater for controlled testing. (PortSwigger)

🧠 Build an authorization test matrix (OWASP WSTG style)

If you want to stop missing access control bugs, build a matrix. OWASP's Web Security Testing Guide includes a dedicated Authorization Testing section and explicitly calls out Testing for Insecure Direct Object References as part of the methodology. (OWASP Foundation)

Create a matrix like:

• Rows = sensitive endpoints (profile, invoices, admin APIs, downloads)
• Columns = roles (anonymous, user A, user B, admin)
• Cells = expected outcome (200, 403, redirect, masked fields)

This is how professionals test. It's not glamorous, but it finds real bugs.

🧿 Common IDOR vulnerability patterns (so you recognize them fast)

Most IDOR vulnerability findings fall into a few repeat patterns:

• Horizontal access: User A can access User B's objects (same role).
• Vertical access: User can access admin-only objects (role escalation).
• Predictable object IDs: Incrementing IDs, short tokens, guessable filenames.
• Indirect IDOR: The app hides the ID, but still accepts it in a request body.
• IDOR in redirects: Sensitive data appears inside redirect responses.

That last one matters because PortSwigger has a lab specifically about data leakage in the body of a redirect response in an access control scenario. (PortSwigger)

🧨 When an IDOR vulnerability turns into “account takeover”

Not every IDOR vulnerability is full takeover. However, some are absolutely explosive.

High-impact outcomes include:

• Viewing private user data (PII, addresses, invoices).
• Extracting secrets (API keys, tokens, reset links).
• Modifying account settings (email change, password reset trigger).
• Performing privileged actions if the endpoint controls role/permissions.

PortSwigger emphasizes that access control weaknesses can lead to serious privilege escalation and unauthorized actions, not just data viewing. (PortSwigger)

🧪 PortSwigger lab walkthrough (safe IDOR vulnerability practice)

Use labs for skill-building because they're legal, repeatable, and designed for exactly this. PortSwigger's Web Security Academy provides a large catalog of labs across vulnerability types. (PortSwigger)

Two excellent IDOR-related labs to practice:

• User ID controlled by request parameter (classic horizontal escalation). (PortSwigger)
• User ID controlled by request parameter with data leakage in redirect (redirect body leak). (PortSwigger)

Walkthrough approach (general, lab-safe):

1. Log in with provided credentials (PortSwigger labs often use wiener:peter). (PortSwigger)
2. Navigate to "My account" and capture the request in proxy history.
3. Send it to Repeater.
4. Change the identifier (username/id).
5. Compare the response for unauthorized data exposure.

If you're practicing the redirect-leak style lab, remember the trick: redirects can still contain sensitive content in the response body, even when the browser navigates away. (PortSwigger)

⚡ Intruder for IDOR vulnerability testing (without being reckless)

Intruder is useful for discovering which references exist and which ones are accessible. That said, don't treat Intruder like a hammer and every server like a nail.

PortSwigger's IDOR testing workflow describes using Intruder (often "Sniper") to test variations of suspected object references in a controlled manner. (PortSwigger)

Safe usage guidelines:

• Use Intruder on labs or explicitly authorized targets only.
• Keep payload ranges tight (test what you need, not the whole internet).
• Add delays and throttle concurrency if the app is sensitive.
• Stop the moment you confirm unauthorized access (you already have the bug).

🧩 Burp helpers for IDOR vulnerability testing (extensions + habits)

Burp gets dramatically better when you run a repeatable workflow:

• Label endpoints and note assumptions.
• Save "good" and "bad" requests.
• Keep screenshots or request/response exports for proof.

You can also add extensions from the BApp ecosystem to help scale specific testing tasks. Burp's extensibility exists to support exactly this kind of workflow improvement. (PortSwigger)

📝 Reporting an IDOR vulnerability (so it gets accepted, not ignored)

A great report is short, surgical, and undeniable.

Include:

• What object was accessed (and why it's sensitive).
• Exactly how to reproduce (3–6 steps).
• Clear evidence (request + response, redacted where appropriate).
• Impact: what a real attacker can do with it.
• Suggested fix (authorization check on the server).

For bug bounty contexts, Bugcrowd's VRT exists as a shared language for severity and prioritization of common vulnerability classes. (Bugcrowd)

🛡️ Fixing IDOR vulnerability issues (developer controls that actually work)

Here's the blunt truth: "hide the ID" isn't a fix. It's cosmetic.

Real fixes include:

• Enforce authorization server-side for every object request.
• Use policy checks like "does requester own this object?" or "does role allow access?"
• Deny by default (explicit allow rules only).
• Log and alert on repeated unauthorized object access attempts.
• Add tests (unit/integration) for access control regressions.

OWASP's testing structure helps you validate these controls consistently across the application surface. (OWASP Foundation)

✅ Final IDOR vulnerability checklist + next step

If you want to reliably find (and prove) an IDOR vulnerability, run this loop:

• Capture baseline request → Repeater proof → Role/object matrix → Clean report.

If you're testing your own site or platform and want help hardening it after you identify access control risk, use:

• Helpdesk Support
• Contact
• Health

❓ Frequently Asked Questions (IDOR vulnerability)

❓ What is an IDOR vulnerability?
An IDOR vulnerability is an access control flaw where changing an object reference lets you access data or actions you shouldn't.

❓ Why is IDOR vulnerability testing so important?
Because access control bugs often expose real user data, admin functions, or money-related actions.

❓ Is IDOR vulnerability testing legal?
Yes, when you test your own systems or follow an authorized bug bounty scope and rules.

❓ What's the fastest way to spot an IDOR vulnerability?
Look for user IDs, usernames, order IDs, or file IDs in requests, then test whether the server validates ownership.

❓ Does a 403 response mean there's no IDOR vulnerability?
Not always. Some apps leak data in redirect bodies, error messages, or partial responses.

❓ What Burp tool is best for IDOR vulnerability proof?
Repeater, because it lets you change one value and compare responses cleanly.

❓ Should I use Intruder for IDOR vulnerability testing?
Only in labs or authorized scopes, and only with tight ranges and safe throttling.

❓ What's the difference between horizontal and vertical IDOR vulnerability?
Horizontal means same-role user-to-user access; vertical means a lower role reaches admin-only objects.

❓ Can GraphQL have IDOR vulnerability issues?
Yes. GraphQL variables often carry object references that still require server-side authorization checks.

❓ Is "randomizing IDs" a real fix for IDOR vulnerability problems?
No. It may reduce guessing, but authorization checks must still be enforced server-side.

❓ How do I write a strong IDOR vulnerability report?
Use short reproduction steps, include the exact request/response evidence, and explain real-world impact.

❓ What evidence should I include for an IDOR vulnerability?
The baseline request, the modified request, and the unauthorized response (redacted if needed).

❓ What makes an IDOR vulnerability high severity?
Access to sensitive data, account changes, financial actions, or admin capabilities.

❓ Can an IDOR vulnerability lead to account takeover?
Yes, if the exposed object includes reset tokens, API keys, session artifacts, or account-change actions.

❓ How do OWASP methods help with IDOR vulnerability testing?
OWASP WSTG provides a structured authorization testing approach, including IDOR testing guidance. (OWASP Foundation)

❓ Which safe lab should I use to practice IDOR vulnerability testing?
PortSwigger Web Security Academy access control labs are designed for safe IDOR practice. (PortSwigger)

❓ Why do some IDOR vulnerability bugs appear only in redirect responses?
Because some apps include sensitive content in the response body even when issuing a redirect. (PortSwigger)

❓ What's the simplest developer-side fix for IDOR vulnerability?
Check authorization on every object access using server-side rules like ownership and role permissions.

📚 Sources & References

• PortSwigger: Access control vulnerabilities (PortSwigger)
• PortSwigger: Insecure direct object references (IDOR) (PortSwigger)
• Burp docs: Check proxy listener (127.0.0.1:8080) (PortSwigger)
• OWASP WSTG: Authorization testing (includes IDOR) (OWASP Foundation)
• PortSwigger lab: Data leakage in redirect (PortSwigger)
• NIST SP 800-115: Security testing & assessment guide (NIST Computer Security Resource Center)

✅ Online Research Verification (what I checked)

• Confirmed Burp's default proxy listener behavior and troubleshooting guidance (127.0.0.1:8080). (PortSwigger)
• Verified OWASP WSTG includes Authorization Testing and explicitly lists IDOR testing. (OWASP Foundation)
• Verified PortSwigger's IDOR definition and access control context. (PortSwigger)
• Verified PortSwigger lab details and the presence of redirect-body leakage in the referenced access control lab. (PortSwigger)
• Cross-checked methodology framing against NIST's testing and assessment guidance. (NIST Computer Security Resource Center)

Related Videos:

Related Posts:

XSS and SSRF Testing: Burp Labs That Build Real Skills

Adobe Genuine Service Explained: What It Does, Why It Runs, and Your Real Options

Burp Suite Intruder Automation: XSS & SSRF in 19 Steps

XSS Prevention: 17 Practical Defenses That Actually Work

CSRF Testing Guide: 17 Practical Steps to Find Vulnerabilities