What Are Insecure Direct Object References

Insecure direct object references (IDOR) are a cybersecurity issue that occurs when a web application developer uses an identifier for direct access to an internal implementation object but provides no additional access control and/or authorization checks. For example, an IDOR vulnerability would happen if the URL of a transaction could be changed through client-side user input to show unauthorized data of another transaction.

In the OWASP (Open Web Application Security Project) Top 10 list in 2013, insecure direct object references were treated as a separate issue ranked at number 4 (see OWASP Top 10 2013 A4). However, in the last OWASP Top 10 in 2017, this category was merged into category A5: Broken access control.

How IDOR Vulnerabilities Happen

Most web applications use simple IDs to reference objects. For example, a user in a database will usually be referred to via the user ID. The same user ID is the primary key to the database column containing user information and is generated automatically. The database key generation algorithm is very simple: it usually uses the next available integer. The same database ID generation mechanisms are used for all other types of database records.

The approach described above is legitimate but not recommended because it could enable the attacker to enumerate all users. If it’s necessary to maintain this approach, the developer must at least make absolutely sure that more than just a reference is needed to access resources. For example, let’s say that the web application displays transaction details using the following URL:

https://www.example.com/transaction.php?id=74656

A malicious hacker could try to substitute the id parameter value 74656 with other similar values, for example:

https://www.example.com/transaction.php?id=74657

The 74657 transaction could be a valid transaction belonging to another user. The malicious hacker should not be authorized to see it. However, if the developer made an error, the attacker would see this transaction and hence we would have an insecure direct object reference vulnerability.

Common Insecure Direct Object Reference Scenarios

IDOR vulnerabilities may happen in the case of password change forms. A badly designed password change form URL might be:

https://www.example.com/change_password.php?userid=1701

This URL would be sent by email upon first providing an email address using a different form. If there are no additional checks, a malicious hacker could try the above URL with userid=1, thus probably gaining access to the administrator account.

IDOR vulnerabilities might also involve filenames, not object IDs. For example, one of the most typical IDOR vulnerabilities is directory traversal (path traversal). In this special case, the user is able to display unauthorized files. For example:

https://www.example.com/display_file.php?file.txt

If there is an IDOR vulnerability associated with the display_file.php script, a malicious hacker could gain access to sensitive file system resources such as the /etc/passwd file:

https://www.example.com/display_file.php?../../../etc/passwd

Insecure Direct Reference Prevention

The OWASP Testing Guide contains a paragraph on how to test for insecure direct object reference vulnerabilities: OTG-AUTHZ-004. Automated solutions are yet not able to detect IDOR vulnerabilities.

The only way to protect against IDOR is to implement strict access control checks. Luckily, modern web frameworks such as Ruby on Rails or Django don’t have problems with IDOR (unless the developer decides to use their own mechanisms instead of the ones provided). Access control is implemented in such frameworks by design. Therefore, we recommend that you use renowned frameworks to develop your web applications and follow the best practices.

Note that some sources recommend preventing IDOR vulnerabilities by using long, hard-to-guess object identifiers, such as the ones used for session IDs. Another proposed similar solution is to use indirect object reference maps with external IDs that are hard to guess. However, we strongly recommend against such approaches because they give a false sense of security and make the attack harder but not impossible.