Application Security
IDOR (Insecure Direct Object Reference)
IDOR, or Insecure Direct Object Reference, is an access control vulnerability in which an application exposes a reference to an internal object, such as a record identifier, and fails to verify that the requesting user is authorized to access that object.
In plain terms
IDOR is when you can see someone else’s data just by changing a number in the URL. If your invoice is at
/invoice/123and changing it to/invoice/124shows a stranger’s invoice, that is IDOR. The app trusted the identifier without checking you are allowed to see it.
IDOR, or Insecure Direct Object Reference, is an access control vulnerability that occurs when an application uses a reference to an internal object, such as a database record identifier, a filename, or a key, in a way that is directly accessible or guessable by the user, and then fails to verify that the user is authorized to access the object that reference points to. The result is that a user can manipulate the reference to access data or perform actions on objects belonging to other users or that should be off limits. IDOR is one of the most common and impactful web vulnerabilities, falling under the broader category of broken access control.
The classic illustration involves an identifier in a request. Suppose a web application lets a user view their order at an address containing an order number. If the application returns the order matching that number without checking that it belongs to the requesting user, then a user can simply change the number to another value and view someone else’s order. The same pattern applies to account details, documents, messages, and any resource referenced by an identifier. The vulnerability is not that the identifier is visible; it is that the application trusts the identifier to imply authorization instead of independently checking that the current user is permitted to access the referenced object.
IDOR arises from a specific failure: missing or inadequate authorization checks at the object level. Applications often correctly authenticate users, confirming who they are, and may even check that a user is allowed to use a feature in general, but then fail to confirm that the specific object being requested belongs to or is permitted for that user. This object-level authorization is exactly what IDOR exploits. Because the check is missing, the application effectively grants access based on knowledge of an identifier rather than on the user’s actual permissions, which is why guessing or enumerating identifiers can expose data across users.
The impact of IDOR ranges from information disclosure to full account takeover and data manipulation, depending on what the referenced objects allow. Reading other users’ records is a confidentiality breach; being able to modify or delete them via the same flaw extends to integrity and availability. When the referenced objects include sensitive personal data, financial records, or administrative functions, the consequences can be severe, and because IDOR is often easy to discover and exploit by simply altering values in requests, it is a frequent finding in assessments and a common cause of real breaches. Identifiers that are sequential or predictable make enumeration trivial, amplifying the exposure.
A crucial point is that obscuring or randomizing identifiers is not a real fix, only a partial mitigation. Replacing sequential identifiers with hard-to-guess random ones, sometimes called using indirect references, makes enumeration harder but does not address the underlying problem, because an attacker who learns or leaks an identifier can still access the object if no authorization check exists. The genuine remedy is to enforce proper authorization on every access to an object: the application must verify, server-side, that the authenticated user is allowed to access or act on the specific object referenced by the request, regardless of how the reference is formatted. Obscurity can complement this but never replace it.
Preventing IDOR therefore centers on consistent, object-level access control. Every request that references an object should be checked against the user’s permissions for that object, ideally through a centralized and systematic authorization mechanism rather than ad hoc checks scattered through the code that are easy to forget. Designing access control so that the default is to deny unless ownership or permission is confirmed, and testing specifically for the ability to access other users’ objects by manipulating references, helps catch and close these flaws. Because IDOR is fundamentally about authorization, it is addressed by the same disciplined access control that defends against broken access control generally.
In practice, IDOR is the vulnerability of letting users reach objects they should not, simply by referencing them, because the application fails to check object-level authorization. It is common, often easy to exploit by changing identifiers in requests, and capable of exposing or altering other users’ data. The reliable defense is enforcing authorization on every object access server-side rather than relying on hidden or unguessable identifiers. Understanding IDOR clarifies why authentication is not enough, why every access must confirm permission to the specific object, and why broken access control remains one of the most serious classes of web vulnerability.