Insecure Direct Object Reference (IDOR)
Insecure Direct Object Reference (IDOR) is an access-control flaw where an application exposes a reference to an internal object — such as a record ID in a URL or API request — and fails to verify the requester is authorized for it, letting attackers access other users' data by changing the identifier.
Insecure Direct Object Reference (IDOR) is a specific and common form of broken access control. It happens when an application uses a client-supplied value — a numeric database ID, filename, account number, or similar — to fetch an object, but does not check that the current user is actually allowed to access that particular object. An attacker simply changes the reference, for example requesting /api/invoice/1002 instead of /api/invoice/1001, and retrieves or modifies data belonging to someone else.
The underlying mistake is trusting the identifier itself as if it were an authorization decision. Sequential or predictable IDs make enumeration trivial, but even random UUIDs do not fix the flaw — obscurity is not authorization. In API-centric applications this is often called Broken Object Level Authorization (BOLA) and is the top risk in the OWASP API Security Top 10; it maps to CWE-639 and sits under the broader broken access control category.
The correct defense is to enforce an ownership or permission check on the server for every object access — verifying that the authenticated user is entitled to the specific record, not merely authenticated. Using indirect references scoped to the session and applying deny-by-default authorization add defense in depth, but per-request server-side authorization is the essential fix that developers must not skip.