How to Exploit IDOR: Step-by-Step (OWASP Juice Shop Lab)

In one line

IDOR is when an app trusts an id you send it: change the id in a request from yours to someone else's, and it hands you their data because it never checks who you are.

What this is, for a beginner

IDOR stands for Insecure Direct Object Reference, one of the most common flaws in the broken access control category that tops the OWASP Top 10. It happens when an application uses a value you can see and change, such as a numeric id in a URL or a JSON body, to look up a record, but never checks that the record actually belongs to you.

Picture an endpoint like /rest/basket/1. If you are user 1, that returns your basket, which is correct. The bug is when you change the 1 to a 2 and the server returns user 2's basket, because it fetched the record by id and forgot to confirm ownership. Authentication worked; authorization is missing. IDOR is dangerous precisely because it is so simple, and nearly invisible to scanners, which cannot tell that basket 5 belongs to a different user than basket 6.

The legal lab we use: OWASP Juice Shop

A deliberately insecure application built by OWASP for exactly this kind of practice. Run it locally so every request hits software you own.

OWASP Juice Shop project page →

Full walkthrough: exploiting it step by step

Step 1 — Stand up the lab

Run OWASP Juice Shop locally with Docker and open it in your browser once it is up.

terminal

docker run --rm -p 3000:3000 bkimminich/juice-shop

Expected result: Juice Shop is serving at http://localhost:3000 and the shop front page loads.

Step 2 — Create two accounts

Register an attacker account and a victim account. Add a product to the victim's basket so it holds data worth stealing, then log back in as the attacker.

Expected result: Two independent accounts exist; the victim basket has an item; you are logged in as the attacker.

Step 3 — Proxy through Burp Suite

Route the browser through Burp Suite, open your basket as the attacker, and find the request the page makes in Burp's HTTP history.

Expected result: A GET request to /rest/basket/{id} returning JSON with your basket contents appears in Burp.

Step 4 — Identify the object reference

The path ends in a number, for example /rest/basket/6. That is your basket id, fully under your control. Your request also carries your JWT in the Authorization header, so you are properly authenticated; the question is whether the server checks authorization.

Burp — your basket request

GET /rest/basket/6 HTTP/1.1
Host: localhost:3000
Authorization: Bearer eyJhbGciOi... (your token)

Expected result: A 200 response containing your basket id and products.

Step 5 — Tamper with the id

Send the request to Repeater and change only the id to a neighbouring value, keeping your own token. You are testing whether your token is allowed to read another user's object.

Burp Repeater — tampered request

GET /rest/basket/5 HTTP/1.1
Host: localhost:3000
Authorization: Bearer eyJhbGciOi... (still YOUR token)

Expected result: A 200 response containing another user's basket, including the victim's item. That is a working IDOR.

Step 6 — Confirm impact with a range

Send to Intruder, set the id as the payload, and run 1 to 20 to show many baskets are readable, not just one. This also solves the Juice Shop challenge for viewing another user's basket.

Burp Intruder — id as payload (1–20)

GET /rest/basket/§1§ HTTP/1.1
Host: localhost:3000
Authorization: Bearer eyJhbGciOi...

Expected result: Multiple 200 responses of differing length, each a different user's basket. Sort by length to spot populated baskets.

Free resource

Get the free 35-week ethical hacking roadmap

The exact order I'd learn this in, every vulnerability and tool, week by week, with the labs to practise each one. Enter your email and I'll send it over, plus one practical lesson each week.

How to detect and fix this

How to detect it

Walk every endpoint that takes an id (path, query, body, or hidden field) and change that id to one belonging to another account; if the data comes back, it is an IDOR.
Test with two low-privilege accounts side by side, replaying one account's request against the other's object. Broken object-level authorization is the top API risk.
Watch for sequential ids, which make enumeration trivial; GUIDs slow an attacker but are not a fix.

How to fix it

Enforce authorization on every object lookup, server-side, on every request: WHERE id = :id AND owner_id = :currentUser, not just WHERE id = :id.
Do not rely on ids being hard to guess. Access control is the fix; unpredictable ids are only a speed bump.
Centralise the ownership check so a new endpoint cannot silently omit it, and add tests asserting user A cannot read user B's objects.

Common beginner mistakes

Changing the Authorization token as well as the id, which just logs you in as the victim and proves nothing. Keep your token; change only the object id.
Testing while logged out. IDOR is about a logged-in user reaching another user's data.
Giving up after one id returns nothing; ids may not be adjacent, so use Intruder over a range.
Assuming a 200 means success without reading the body, and testing against a live site you do not own.

FAQ

What is the difference between IDOR and broken access control?

IDOR is a specific type of broken access control. Broken access control is the broad category, and IDOR is the common case where the app exposes a direct reference to an object, like an id, and fails to check ownership when you change it.

Is IDOR easy to find?

Conceptually yes, which is why beginners find real ones quickly, but it takes patience because you test many endpoints by hand. Scanners usually miss it because they cannot tell that one object belongs to a different user.

Which lab is best for practising IDOR?

OWASP Juice Shop, used here, has a clear basket IDOR, and the PortSwigger Web Security Academy has an excellent free set of access-control labs covering IDOR variations. Both are legal to attack.

Where to go from here

You just exploited one vulnerability in a lab. Here's the structured path.

Scattered tutorials teach you tricks; they don't make you a pentester. My mentorship is 35 weeks of exactly this, every vulnerability and tool in a deliberate order, on real labs, with one-on-one feedback on your work so your mistakes get caught early instead of becoming habits.

See the mentorship

Keep practising

How to Exploit Broken Authentication How to Use Burp Suite How to Exploit SQL Injection