Insecure Direct Object Reference (IDOR) is one of the most common yet underestimated web application vulnerabilities. It often looks harmless, is easy to miss, and can exist even in well-built systems. But when exploited, IDOR can expose sensitive user data and completely break access control.
This post explains what IDOR is, how it occurs, realistic examples, and how it should be prevented.
What is IDOR?
IDOR (Insecure Direct Object Reference) occurs when an application exposes internal object identifiers — such as user IDs, file IDs, order numbers, or record IDs — and fails to verify whether the requesting user is authorized to access that object.
In simple terms: If a user can access another user's data just by changing an ID in a request, the application is vulnerable to IDOR.
Why IDOR Is Dangerous
IDOR is dangerous because it breaks authorization, not authentication.
Even if a user is fully logged in, weak authorization checks can allow them to:
- View other users' personal information
- Modify or delete records they don't own
- Download private files
- Access restricted resources
Many large-scale data leaks have happened not because of advanced hacking techniques, but because of missing authorization logic.
Simple IDOR Example
Consider the following request:
GET /api/user/profile?id=101The server returns the profile details of user 101.
If the user changes the request to:
GET /api/user/profile?id=102And the server responds with another user's profile without validating ownership, an IDOR vulnerability exists.
The issue here is not exposing the ID — it is the lack of authorization validation on the server.
Real-World IDOR Scenario
Imagine an online learning platform where users can download certificates:
GET /api/certificates/download?cert_id=5567If certificate IDs are predictable and the server does not verify whether the certificate belongs to the logged-in user, anyone can download certificates issued to others by modifying the ID.
This is a realistic and very common IDOR scenario.
Common Places Where IDOR Appears
IDOR vulnerabilities are frequently found in:
- REST APIs
- Mobile application backends
- File download endpoints
- Invoice and order management systems
- Profile update and delete APIs
Anywhere an object is accessed using an identifier is a potential IDOR risk.
How IDOR Is Tested (Security Perspective)
From a security testing standpoint, IDOR testing usually involves:
- Intercepting a request using a proxy tool
- Identifying object references (IDs, UUIDs, filenames)
- Modifying the reference to another valid value
- Observing the server's response
If the application returns valid data instead of denying access, authorization is likely broken.
How Developers Can Prevent IDOR
The solution is not hiding or encrypting IDs.
Proper prevention includes:
- Enforcing server-side authorization checks
- Validating object ownership for every request
- Implementing role-based or attribute-based access control
- Rejecting requests when the user lacks permission
The core question the server must always answer is: "Is this user allowed to access this object?"
If the answer is no, the request should fail.
IDOR vs Authentication Issues
IDOR is not an authentication problem.
A user may be:
- Fully logged in
- Using a valid session
- Properly authenticated
And still exploit IDOR due to missing authorization checks.
Final Thoughts
IDOR is simple to understand but severe in impact. Many applications fail not because of complex vulnerabilities, but because basic authorization rules are not enforced.
If you are a developer, always validate access on the server. If you are a security tester, always test object references.
IDOR is a reminder that security is not about hiding data — it's about controlling access.
Connect with me on LinkedIn: https://acesse.one/AkshayDamle