Insecure Direct Object Reference (IDOR)
detect, understand, remediate
IDOR occurs when an application exposes internal object references without authorisation checks, allowing attackers to access or modify other users' data by simply changing a parameter value.
No credit card required. Free plan available forever.
What is insecure direct object reference (IDOR)?
Insecure direct object reference (IDOR) is an access control vulnerability that occurs when an application exposes internal object identifiers (such as database IDs, file names, or resource keys) and fails to verify that the requesting user is authorised to access the referenced object. An attacker simply modifies the identifier in a request (e.g. changing /api/users/123 to /api/users/124) to access another user's data.
IDOR is the most common form of broken access control and frequently appears in APIs, web applications, and mobile backends. It can lead to horizontal privilege escalation (accessing other users' data at the same privilege level) or vertical privilege escalation (accessing admin-level resources). The impact ranges from reading another user's profile to downloading sensitive documents, modifying account settings, or deleting records belonging to other users.
What makes IDOR particularly dangerous is its simplicity. Unlike complex injection attacks, IDOR requires no special tools or expertise, just the ability to change a number in a URL or API request. Automated tools can enumerate thousands of sequential IDs in seconds, making mass data extraction trivial once an IDOR is discovered. Despite being easy to understand and prevent, IDOR remains one of the most frequently reported vulnerabilities in bug bounty programmes and penetration tests.
How it works
User requests own resource
An authenticated user makes a legitimate request to access their own data, such as GET /api/users/123/profile or GET /api/orders/456.
Attacker modifies the identifier
The attacker changes the ID parameter to reference another user's resource, for example changing 123 to 124, or 456 to 457.
Server returns unauthorised data
The server processes the request without checking whether the authenticated user is authorised to access the requested resource. It returns the other user's data.
Mass enumeration and extraction
The attacker automates the process, iterating through sequential or predictable IDs to extract data for all users, orders, documents, or other resources.
Common causes
Missing server-side authorisation checks
API endpoints and page handlers that authenticate the user but never verify whether the user owns or has permission to access the specific resource being requested.
Sequential and predictable identifiers
Using auto-incrementing database IDs or predictable patterns for resource identifiers, making it trivial for attackers to guess valid IDs for other users' resources.
Trusting client-side access controls
Hiding UI elements (buttons, links, menu items) based on user role without enforcing the same restrictions server-side. Attackers bypass the UI entirely by calling the API directly.
API endpoints without ownership validation
REST APIs that accept resource IDs in URL parameters, query strings, or request bodies without validating that the authenticated user is the resource owner or has delegated access.
How to detect it
Automated detection
- SecPortal's authenticated scanner tests for horizontal and vertical privilege escalation by replaying requests with modified resource identifiers
- SecPortal detects endpoints using sequential numeric IDs and tests parameter tampering across user contexts to identify missing authorisation checks
- Code scanning identifies API route handlers that extract resource IDs from parameters without corresponding ownership or permission validation queries
Manual testing
- Create two test accounts, capture API requests from one account, and replay them using the other account's session to test for horizontal access
- Increment or decrement numeric IDs in URLs and request bodies to check whether the server returns data belonging to other users
- Test with different user roles (regular user vs admin, free vs premium) to identify vertical privilege escalation through IDOR
How to fix it
Enforce server-side authorisation on every request
Every API endpoint and page handler must verify that the authenticated user has permission to access the specific resource being requested. Never rely on the client to enforce access control.
Use indirect reference maps or UUIDs
Replace sequential numeric IDs with UUIDs or indirect reference maps that are scoped to the user's session. This makes valid IDs impossible to guess, adding a layer of defence alongside proper authorisation checks.
Implement deny-by-default access control
Design access control so that requests are denied by default unless an explicit authorisation rule grants access. This prevents new endpoints from being accidentally exposed without access control.
Add automated authorisation testing to CI/CD
Include automated IDOR tests in your testing pipeline. Create integration tests that attempt to access resources across user boundaries and verify that access is correctly denied.
Compliance impact
Related vulnerabilities
Detect IDOR automatically
SecPortal tests for horizontal and vertical privilege escalation, parameter tampering, and sequential ID manipulation. Start free.
No credit card required. Free plan available forever.