Insecure Direct Object Reference (IDOR) is an access-control vulnerability that occurs when an application exposes a reference to an internal object – such as a database record, file, or resource – and fails to verify that the user requesting it is actually authorized to access that specific object. As a result, an attacker can manipulate the reference (for example, changing an ID number in a URL or request) to access objects belonging to other users or objects they should not be able to reach. IDOR is essentially a failure to enforce authorization at the level of individual objects, and it is closely related to – often used interchangeably with – Broken Object Level Authorization (BOLA) in the API context.
The classic example makes it concrete: an application serves a user’s invoice at a URL like example.com/invoice?id=1001. If the application only checks that the user is logged in but not that invoice 1001 actually belongs to them, an attacker can change the ID to 1002, 1003, and so on, viewing other users’ invoices. The “direct object reference” is the exposed identifier; it becomes “insecure” when the application trusts it without an authorization check. References need not be sequential numbers – any predictable or discoverable identifier can be abused, and relying on obscure or hard-to-guess IDs is not a real defense, because attackers can enumerate, leak, or otherwise obtain them.
IDOR can affect any exposed object: user records, documents, files, account settings, messages, and more. Depending on the endpoint, the attacker may be able not only to read unauthorized data but also to modify or delete it. The impact is unauthorized access to and manipulation of sensitive data, which can lead to privacy violations, data breaches, and fraud.
IDOR is particularly common and impactful in APIs, which frequently expose object identifiers and operate on resources requested by ID. Because each malicious request looks like a perfectly valid, well-formed request – just referencing a different object – IDOR typically evades firewalls, gateways, and generic scanners, which see nothing malformed. It is a logic and authorization flaw, not a syntactic one.
Preventing IDOR requires enforcing proper authorization on the server for every object access: verifying that the authenticated user is entitled to the specific object they request, tying each request to the user’s permissions and ownership, and never assuming that possession or knowledge of a reference implies authorization. Additional measures include using indirect or per-user reference mappings, avoiding exposure of internal identifiers where feasible, and testing endpoints specifically for object-level access violations. The fundamental fix is the same as for BOLA: authorization must be checked at the object level on every request, on the server side.