IDOR Explained

IDOR, insecure direct object reference, is when an application uses a value like a numeric ID to fetch data but never checks that the requesting user owns that data. Change the ID in the request and you read someone else's records. It is a form of broken access control, the most common high severity finding in real testing, and no scanner reliably catches it.

What IDOR is

An app shows your invoice at /invoice?id=1043. You change it to 1044 and see another customer's invoice. The server checked you were logged in but never checked the invoice belonged to you. That gap is IDOR.

Why scanners miss it

A scanner cannot know that invoice 1044 should not be yours. It has no concept of who owns what. Only a human testing with two accounts can prove the authorisation gap, which is exactly why manual testing still matters.

How to find it, step by step

1. Create two accounts, A and B
2. As user A, capture a request containing an object identifier
3. Replay it with B's session but A's identifier
4. If B receives A's data, that is IDOR
5. Test every HTTP method, GET may be protected while DELETE is not

A proxy like Burp makes this easy, covered in the Burp Suite tutorial.

Where IDOR hides

Real impact

IDOR ranges from reading another user's profile to full data breaches. On a banking or healthcare app it is critical. If the same flaw allows modification or deletion, not just reading, it is worse. Report the impact, not just the changed ID.

IDOR and BOLA

Same bug, different name. IDOR is the older web term, BOLA is the API specific naming and the top API risk. Detail in BOLA explained.

The fix developers keep missing

Switching from sequential IDs to random ones is not a fix. It hides the object, it does not authorise access. IDs leak through search, logs and links. The real fix is checking ownership on every request, in the data layer, scoped to the logged in user.

Practise this

Find IDOR on deliberately vulnerable apps with two accounts. Free labs on Hacklido.