Insecure direct object references (IDOR)
What are insecure direct object references?
Insecure direct object references (IDOR) are vulnerabilities that occur when a web application developer uses only identifiers to directly point to page elements that should be subject to access control or require authorization.
For example, an IDOR vulnerability happens if the URL of a transaction contains the transaction ID, and just by providing a different transaction ID, you can access information about a transaction that belongs to another user.
| Severity: |
 |
medium severity |
| Prevalence: |
|
discovered rarely |
| Scope: |
|
may appear in all web applications |
| Technical impact: | access to sensitive information | |
| Worst-case consequences: | sensitive information breach | |
| Quick fix: | implement strict access control checks |
What does insecure direct object reference mean?
The term insecure direct object reference means that a web application is directly referring to a certain internal object, such as a transaction number or user ID, but this reference is publicly visible, open to direct access, and not secured using any form of validation, authorization, or access control. The term was introduced by the Open Web Application Security Project (OWASP) in the OWASP Top 10 for 2007 as a separate category A4 Insecure Direct Object Reference. In 2017, it was merged into A5 Broken Access Control along with other access control issues, and later carried over to the 2021 list under A1 Broken Access Control.
How do IDOR vulnerabilities happen?
Most web applications use simple unique identifiers to reference server-side objects. For example, a user in a database will usually be referred to via a unique user ID. The same user ID is the primary key to the database column containing user information, and it is generated automatically. The database key generation algorithm is based on simple incrementing – it usually uses the next available integer. The same database ID generation mechanisms are used for all other types of database records.
Such IDs often see client-side use by web applications and APIs. When sent in URLs via regular HTTP requests using the GET method, the IDs are clearly visible both in the web browser and in request headers, which makes them easily accessible to attackers. Referring directly to internal IDs in this way is not recommended for security reasons because it could enable attackers to perform extensive enumeration (for example, find all user IDs). If there is no other way of referring to an internal object, the developer must at least ensure access control so resource access requires more than just a reference and generic page authentication.
For example, let’s say that a web application displays transaction details using the following URL:
https://www.example.com/transaction.php?id=74656A malicious hacker could try tampering with the id parameter value and substituting other, similar values for 74656, for example:
https://www.example.com/transaction.php?id=74657Depending on the application, transaction 74657 could be a valid transaction associated with another user account, and the malicious hacker should not be authorized to see it. However, if the developer failed to implement authorization checks before granting access to the transaction, the attacker may be able to see it. In that case, we would have an insecure direct object reference vulnerability.
Examples of common IDOR vulnerabilities
IDOR vulnerabilities often appear in password change forms. A badly designed password change form URL might be:
https://www.example.com/change_password.php?userid=1701You might get this URL in a confirmation email after 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 potentially gaining access to the administrator account (the ID of the administrator is often 1).
IDOR vulnerabilities might also involve filenames, not object IDs. For example, directory traversal (path traversal) is often considered to be a type of IDOR vulnerability. In this special case of IDOR, the user is able to display files without authorization. For example:
https://www.example.com/display_file.php?file.txtIf 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 by manipulating user input (in this case, simply changing the URL) to navigate to that resource instead of file.txt:
https://www.example.com/display_file.php?../../../etc/passwdHow to detect IDOR vulnerabilities?
Insecure direct object references are a type of access control vulnerability that cannot be directly detected using automated security testing tools (except in the special case of path traversal vulnerabilities). Because you can’t use vulnerability scanning to find them, identifying IDORs requires manual penetration testing and security-focused code reviews.
How to prevent IDOR attacks?
The only way to protect against IDORs is to implement strict access control checks for all sensitive objects. Luckily, modern back-end development frameworks such as Ruby on Rails or Django don’t have problems with IDOR (unless the software developer decides to use their own access mechanisms rather than the built-in ones). With such frameworks, access control is implemented securely by design, so it is best practice to use reputable frameworks to develop your web applications and follow their documented methods of object access control. If that is not possible, you should use secure cryptographic hashes of your identifiers instead of using the identifiers directly.
You may see some sources saying that to prevent IDOR vulnerabilities, you should use long, hard-to-guess object identifiers, such as the ones used for session management or UUIDs. A related solution is to use indirect object reference maps with external IDs that are hard to guess. However, we strongly advise against using any such approaches because they give you a false sense of security while only making attacks harder but not impossible.
Frequently asked questions
What are insecure direct object references?
Insecure direct object references (IDOR) are a cybersecurity issue caused by bad development practices. If the developer references internal application objects using a publicly accessible ID and does not use proper access control and/or authorization to verify access, this causes an IDOR vulnerability.
How dangerous are insecure direct object references?
IDOR vulnerabilities may expose information belonging to other users, causing sensitive data breaches or horizontal privilege escalation. In worst-case scenarios, they may expose sensitive information belonging to application administrators, which may allow for vertical privilege escalation – the attacker may be able to assume the identity of the web app admin and ultimately even gain access to the web server.
Read about horizontal and vertical privilege escalation and its consequences.
How to detect and avoid insecure direct object references?
IDOR vulnerabilities can only be discovered through manual pentesting, since they cannot be found automatically using application security tools. The best way to avoid IDOR vulnerabilities is to follow secure development practices for web applications and implement strict access control for all internal application objects. In practice, developers should use modern web frameworks such as Ruby on Rails or Django, which prevent IDOR by design.
| Classification | ID |
|---|---|
| CAPEC | 180 |
| CWE | 284 |
| WASC | 02 |
| OWASP 2021 | A1 |
Related blog posts
- Insecure direct object reference (IDOR) vulnerabilities in brief
- IDOR, you DOR, everybody DOR: The dangers of direct object references
Written by: Tomasz Andrzej Nidecki, reviewed by: Benjamin Daniel Mussler