What IDOR Is
An Insecure Direct Object Reference occurs when an application exposes a reference to an internal object, such as a database row identifier, and fails to check that the current user is authorized to access that object. Swapping one identifier for another then reveals or modifies data belonging to someone else.
A Typical Example
- A user views their invoice at a path that ends with their invoice number.
- They change the number to a nearby value and receive another customer's invoice.
- The server returned the record because it only checked authentication, not authorization for that specific object.
Defenses
- Enforce an authorization check on every object access, confirming the requester owns or may access it.
- Prefer scoping queries to the current user, for example fetching by both record id and owner id together.
- Treat unguessable identifiers like random tokens as defense in depth, never as the primary control.
Key idea
IDOR is an authorization gap, so check ownership on every object reference instead of assuming that a logged in user may touch any id they can name.