IDOR is an access-control flaw: an app exposes a reference to an internal object (a record ID in a URL or request) and acts on it without checking the current user is allowed to access that object. Because the reference is often predictable (a sequential number), an attacker just changes it and - if ownership isn't verified - reaches other users' data or actions. It's a specific, very common form of broken access control (OWASP's #1 category), dangerous because it's simple: no exploit, just altering a trusted identifier. It applies to reads and writes - view, modify, or delete others' objects - and attackers automate it to harvest data at scale. Scanners miss it because detecting it needs business context (who should access what) and usually two accounts to compare. Fix: a server-side authorization check on every object reference, on every endpoint incl. APIs. Unpredictable IDs help but aren't a substitute. Closely related: BOLA in REST APIs.
// 01 What IDOR is
An insecure direct object reference (IDOR) is an access-control flaw in which an application exposes a reference to an internal object - such as a record ID in a URL or request - and then acts on that reference without checking whether the current user is actually allowed to access that object. Because the reference is often a predictable value like a sequential number, an attacker can simply change it to another value and, if the application doesn't verify ownership or permission, gain access to data or actions belonging to other users. IDOR is a specific and very common form of broken access control - the category that sits at number one in the OWASP Top 10. It's dangerous precisely because it's simple: no complex exploit is needed, just altering an identifier the application trusted the user not to tamper with.
// 02 How an IDOR attack works
The user notices a request contains a reference to an object they own - an account, invoice, message or file identified by a number or other value. The attacker changes that value to one belonging to a different user and re-sends the request. If the application retrieves and returns the object based purely on the identifier, without checking the requesting user is authorised for it, the attacker receives someone else's data - or is able to perform an action on someone else's object. The same idea applies to actions as well as reads, so an IDOR can allow not just viewing other people's data but also modifying or deleting it. And because valid identifiers are often sequential, attackers automate the attack - iterating through many identifier values to harvest data at scale, turning a single-record bug into a mass data breach. This is the same class of flaw as BOLA (broken object-level authorization) in APIs - IDOR is the classic web name for it.
// 03 Why scanners miss IDOR
Automated scanners struggle with IDOR because detecting it requires understanding who should be allowed to access what - application-specific business context a scanner doesn't have. A scanner can see that a request returns data, but it cannot generally know that the data belongs to a different user and that returning it is a violation. Properly testing for IDOR usually needs at least two separate user accounts so the tester can take an identifier that belongs to one user and try to access it as another, then judge whether the response reveals unauthorised data. That comparison - and the judgement about what constitutes a violation - is human work. This is exactly why IDOR and related access-control flaws are consistently found by skilled manual testing but frequently missed by automated tools alone, and why we treat multi-account authorization testing as core to every web app and API engagement - the same reason scanners miss BOLA.
// 04 How to prevent IDOR
The core fix is to enforce an authorization check on every request that references an object: before returning or acting on an object, the application must verify the authenticated user is actually permitted to access that specific object - rather than trusting the identifier supplied by the client. This check must happen server-side and on every relevant endpoint, including APIs (where object-level checks are most often forgotten). Using unpredictable identifiers - random values instead of sequential numbers - raises the difficulty of guessing valid references, but it is not a substitute for the authorization check: obscurity alone is not access control, and a leaked or logged ID still works. The reliable defences: centralise access-control logic so it's applied consistently, test it with multiple user roles, and treat every client-supplied reference as untrusted. It maps directly to the object-authorization discipline that also stops mass assignment.
// 05 Frequently asked questions
What is an insecure direct object reference?
An access-control flaw where an application exposes a reference to an internal object - a record ID in a URL or request - and acts on it without checking whether the current user is allowed to access that object. Because the reference is often a predictable value like a sequential number, an attacker can change it and, if ownership isn't verified, reach data or actions belonging to other users. IDOR is a specific and very common form of broken access control, dangerous because it's simple - no exploit is needed, just altering a trusted identifier.
How does an IDOR attack work?
The user sees a request containing a reference to an object they own - an account, invoice, message or file identified by a number. The attacker changes that value to one belonging to another user and re-sends the request. If the app retrieves and returns the object based purely on the identifier, without checking authorisation, the attacker receives someone else's data or acts on someone else's object. It applies to actions as well as reads, so it can allow viewing, modifying or deleting others' data - and attackers automate it, iterating through identifiers to harvest data at scale.
Why do scanners miss IDOR?
Detecting IDOR requires understanding who should access what - application-specific business context a scanner lacks. A scanner sees that a request returns data but can't generally know the data belongs to a different user. Proper testing needs at least two accounts, so the tester can take an identifier belonging to one user and try to access it as another, then judge whether the response reveals unauthorised data. That comparison and judgement is human work, which is why IDOR is consistently found by skilled manual testing but missed by automated tools alone.
How do you prevent IDOR?
Enforce an authorization check on every request that references an object: before returning or acting on it, verify the authenticated user is permitted to access that specific object, rather than trusting the client-supplied identifier. This must happen server-side and on every endpoint including APIs. Unpredictable identifiers raise the guessing difficulty but aren't a substitute - obscurity is not access control. Centralise access-control logic, test with multiple roles, and treat every client-supplied reference as untrusted.
// 06 Related reading
- BOLA and REST APIs: what scanners miss — the API form of the same flaw.
- Mass assignment and business logic vulnerabilities.
- OWASP Top 10 in real engagements — why access control leads.