An insecure direct object reference (IDOR) is an access control vulnerability where unvalidated user input can be used for unauthorized access to resources or operations. IDORs can have serious consequences for cybersecurity and be very hard to find, though exploiting them can be as simple as manually changing a URL parameter. Here’s your pocket guide to insecure direct object references.

Behind the Name: IDORs in the OWASP Top 10

When compiling its list of top 10 web application vulnerabilities, OWASP (the Open Web Application Security Project) popularized the term “insecure direct object reference” as a collective name for vulnerabilities that allowed attackers to reference objects directly and thus gain unauthorized access to application resources. Vulnerable web applications expose a direct reference to an internal implementation object, for example a user ID, and then fail to run proper authorization checks to ensure that the current user is permitted to access a resource or operation.

To formalize the simple (and common) idea that you can access resources and operations by manually messing about with a URL or form parameter, the OWASP Top 10 for 2007 introduced the separate category A4 Insecure Direct Object Reference. In 2017, this class of vulnerabilities was merged into A5 Broken Access Control.

Strictly speaking, an exposed direct object reference is not dangerous in itself – it merely reveals some internal implementation details. To be considered an IDOR, the direct object reference must be combined with insufficient access control, and this is the meaning used in this article (following OWASP).

IDORs in Action

An insecure direct object reference vulnerability occurs when the following three conditions are met:

1. The application reveals a direct reference to an internal resource or operation.
2. The user is able to manipulate a URL or form parameter to modify the direct reference.
3. The application grants access to the internal object without checking if the user is authorized.

While all this looks very formal, it can also be very simple. Let’s say that an online store sends you an email with a personal one-time promo code for spending a certain amount in the store. It then processes a URL such as www.example.com/applydiscount?promocode=123 without checking if the current user actually qualifies for the specified promo discount. If you see this during checkout, you might be tempted to type in other promo codes to see what happens. If you change the promocode parameter value to, say, 120 or 125 and get a different discount, then congratulations! You’ve just exploited an IDOR vulnerability.

Another trivial IDOR example could be a user ID included in the URL, such as www.example.com/userinfo/73627. Without proper session management and access control, the site might allow you to enumerate user IDs of other users, potentially exposing confidential information.

IDOR Types

Whether through URLs or form parameters, applications can expose lots of internal implementation details. Some parameters, like the promo code above, might be used for direct financial benefit. Others might be used to extract sensitive data or escalate access privileges. Depending on the attack possibilities they offer, we can roughly divide IDOR vulnerabilities into four classes (though in practice, these will often overlap):

• Obtaining unauthorized data access: Exposed object references may reveal direct database IDs, allowing attackers to retrieve database records containing sensitive information. Database key names and values can also be used to prepare SQL injection payloads.
• Performing unauthorized operations: By manipulating unvalidated user ID values, command names, or API keys, attackers can execute unauthorized operations in the application. Examples could include forcing a password change to take over a user’s account, executing administrative commands to add users or escalate privileges, and getting access to paid-for or rate-limited application APIs or features.
• Manipulating application objects: Access to internal object references can allow unauthorized users to change the internal state and data of the application. As a result of this vulnerability, attackers might tamper with session variables, for example to alter data, elevate privileges, or access restricted functionality.
• Getting direct access to files: Typically combined with path traversal, this type of IDOR lets attackers manipulate file system resources. This could allow them to upload files, manipulate other users’ data, or download paid content for free.

Even though many IDORs are significant vulnerabilities in their own right, they are typically exploited in combination with other attack vectors.

Detecting IDORs

For any serious security researcher, seeing an exposed internal identifier is an immediate invitation to test IDOR vulnerabilities, especially as they are a solid source of bug bounty payouts. To identify a potentially insecure object reference, you need to have some idea of how a specific application or website works, how it processes HTTP requests, and what information it should and should not reveal in its HTTP responses. Especially for more advanced vulnerabilities that involve passing data through APIs, detecting IDORs can be tricky.

For practical examples of ways to test for IDORs, see the OWASP page on testing for insecure direct object references.

Preventing IDOR Vulnerabilities

While they don’t address the root cause of IDOR vulnerabilities, there are a few ways to mitigate the risk posed by direct references. The first approach is to replace them with indirect object references that are then internally mapped to actual objects. This could mean using a temporary per-session reference map populated only with values valid for a specific user and associated with random, non-sequential keys.

Using secure hashes instead of actual object references is another way to make it harder for attackers to tamper with user-controllable values. See the OWASP IDOR Prevention Cheat Sheet for detailed recommendations on replacing direct identifiers with secure salted hashes.

Both these methods are effective at hiding internal implementation details but don’t address the underlying access control issue. A more robust approach to eliminating IDOR vulnerabilities is to ensure proper session management and object-level user access control checks. That way, even if a determined attacker manages to discover an internal object reference and manipulate it, they will not obtain unauthorized access.