Exploiting IDORs: detection, impact and prevention
An IDOR (Insecure Direct Object Reference) happens when an application lets you access and manipulate internal objects, such as a database ID or a filename, without verifying the user is authorised. It is detected by cross-testing identifiers between two different sessions, and prevented with per-object authorisation, unpredictable identifiers and input validation.

What is an IDOR?
An IDOR (Insecure Direct Object Reference) is a security vulnerability that occurs when an attacker can directly access and manipulate the application’s internal objects — such as a database ID or a filename — without proper authorisation.
This vulnerability is especially dangerous because it can let an attacker reach confidential information or perform malicious actions on behalf of a legitimate user.
Applications are increasingly part of everyday life, from online shopping to managing personal finances. But as their popularity grows, so do the security threats, and IDOR is one of the most frequent.
For example, on an e-commerce site an attacker could exploit an IDOR to change the price of a product, or even to access a user’s payment data without authorisation.
A concrete example
Picture an “actor” who wants to use an application that displays personal documents. They own a document with the identifier id=1000, and to reach it they only need to visit:
https://www.example-idor.com/document?id=1000
Now, what happens if the user changes id=1000 to id=2000, which belongs to someone else’s document?
If the vulnerability is present, the application will respond successfully and grant access to the other person’s document.

How to detect IDORs
- Review every input in the application looking for numeric, alphanumeric or any other kind of identifier that could identify an object and grant ownership of it to a particular user.
- Walk the entire flow with two different users to identify those unique object identifiers that could be affected. Once found, cross them: try user A’s identifier inside user B’s session, and the other way around.
- Use an intercepting proxy during testing, such as Burp Suite or OWASP ZAP, so you can see the full request and response and find every possible vulnerable point.
- Add helper plugins to those proxies to automate detection. I recommend AutoRepeater or Autorize for Burp Suite.
How to prevent IDOR
The good news is that IDOR is preventable. These are the practices with the biggest impact:
- User input validation. Validate every input made by the user to make sure it does not contain malicious characters that could exploit the vulnerability.
- Proper authentication and authorisation. Applications need mechanisms that guarantee users only access the information and functions that belong to them.
- Use of session tokens. Session tokens are a way to authenticate and authorise securely, and they help prevent IDOR attacks.
- Limiting direct access to internal objects. Avoid exposing database IDs or filenames and use random identifiers instead.
In short: IDOR is a real threat to applications, but with good security practices it can be prevented.


