Monitor for sequential integer IDs in API requests and check if changing them exposes data belonging to other users. Validate that the server verifies ownership for every object access, not just at the login stage.
The Anatomy of an IDOR Request
Insecure Direct Object Reference (IDOR) occurs when an application exposes internal implementation objects, such as database keys or file names, to the user without proper access control. The application assumes that because a user is authenticated, they are authorised to access the specific resource requested. This assumption fails when the application does not verify that the authenticated user owns or has permission to view the specific object identified by the parameter.
Imagine a web application where users can view their profile details. The URL might look like example.com/profile?id=123. If you change the number to 124 and the server returns the profile data for a different user, the application has an IDOR vulnerability. The server accepted the input and processed it without checking if the current session belongs to user 124. This is a failure of authorisation, not authentication. The user is who they say they are, but the system fails to check what they are allowed to do.
Identifying Susceptible Parameters
Not all parameters are equally likely to be vulnerable. You must identify which inputs directly map to server-side objects. Integer parameters are the most common target because developers often use auto-incrementing database primary keys. These keys are sequential, making it easy for an attacker to guess valid values. If you see parameters like user_id, order_id, invoice_number or ticket_id in GET or POST requests, treat them as high-risk candidates for testing.
String-based identifiers, such as UUIDs (Universally Unique Identifiers), are harder to guess but not immune to IDOR. If the application does not enforce ownership checks, a user with a valid UUID for another user’s resource can still access it. The complexity of the ID format does not replace the need for server-side verification. The security lies in the logic that checks permissions, not in the obscurity of the identifier.
| Signal | Where to look | What it may mean |
|---|---|---|
| Sequential integer IDs | URL parameters, JSON bodies, XML payloads | High risk of IDOR if no ownership check exists |
| 200 OK on modified ID | Server response codes | Successful unauthorised access confirmed |
| 403 Forbidden on modified ID | Server response codes | Access control is likely working correctly |
| Consistent response structure | API response bodies | Application returns data regardless of ownership |
Analysing Server Logs for Anomalies
Server logs provide a historical record of access patterns that can reveal IDOR issues after they occur. Look for sequences of requests from a single session or IP address that access multiple object IDs rapidly. This behaviour often indicates automated scanning or manual testing by an attacker. If the logs show a user accessing IDs that are significantly higher or lower than their own, or accessing IDs belonging to known other users, this is a strong indicator of an IDOR exploit.
Pay attention to the response codes in these logs. A 200 OK status code indicates the server successfully processed the request and returned data. If this happens for many different object IDs from one session, the application is likely failing to enforce access controls. Contrast this with 403 Forbidden or 401 Unauthorised responses, which indicate that the application correctly blocked the request. The absence of these error codes for out-of-bound IDs is a critical finding.
Manual Verification Techniques
Automated tools are useful for finding syntax errors but often miss logical flaws like IDOR. You must manually verify the access controls. Start by authenticating as a low-privilege user and noting the object IDs they can access. Then, modify these IDs to test access to other resources. Change the ID to a value that is likely to exist, such as incrementing by one. If the server returns data, you have confirmed the vulnerability.
Do not rely solely on URL parameters. Check POST, PUT and DELETE requests as well. An attacker might change the ID in a JSON body to modify or delete another user’s data. This is often more dangerous than reading data because it alters the state of the application. Test every state-changing action with modified IDs. Ensure that the application validates ownership for write operations just as strictly as for read operations.
Common Blind Spots in Detection
Developers often focus on authentication and assume that session management handles authorisation. This is a dangerous misconception. A user can have a valid session token but still lack permission to access specific resources. Another blind spot is the assumption that complex IDs prevent guessing. While UUIDs are hard to guess, they are often stored in databases or exposed in other parts of the application, making them discoverable. If the application does not check ownership, the complexity of the ID is irrelevant.
Another common oversight is neglecting horizontal privilege escalation. This occurs when a user accesses resources belonging to another user with the same privilege level. Vertical privilege escalation, where a user accesses admin resources, is often tested more rigorously. However, horizontal escalation is more common and easier to exploit because the data structure and access patterns are similar. Ensure your testing covers both types of escalation.
See also: Stop Remote Desktop Abuse: Priority Defences and Hidden Risks
Mitigation Strategies Beyond Obscurity
The primary defence against IDOR is server-side access control checks. Every request that accesses an object must verify that the authenticated user has permission to access that specific object. This check should happen before the data is retrieved from the database or file system. Do not rely on client-side controls or hiding IDs in the URL. These measures can be bypassed easily.
Using indirect references can also help. Instead of exposing database primary keys, use an internal mapping table that assigns a random token to each object. The application looks up the token to find the actual object ID. This adds a layer of indirection that makes guessing difficult. However, this is not a substitute for proper access control. The server must still verify that the token belongs to the requesting user.
Integrating IDOR Checks into CI/CD
Incorporating IDOR testing into your continuous integration and continuous deployment (CI/CD) pipeline helps catch vulnerabilities early. Static application security testing (SAST) tools can identify code patterns that lack access control checks. However, these tools produce false positives and cannot confirm logical flaws. Dynamic application security testing (DAST) tools can simulate attacks but may miss complex business logic.
Manual penetration testing remains the gold standard for detecting IDOR. Schedule regular manual tests that focus specifically on object access controls. Train your development team to recognise IDOR risks and to implement proper authorisation checks. Code reviews should specifically look for missing ownership verification in functions that handle user-specific data. This cultural shift ensures that security is considered at every stage of development.
Key takeaways
- Sequential numeric IDs in request parameters are a primary indicator of potential IDOR vulnerabilities.
- Server logs showing successful data retrieval after ID manipulation confirm a lack of authorisation checks.
- Automated scanning tools often miss logical flaws, requiring manual verification of access controls.
IDOR vulnerabilities persist because developers confuse authentication with authorisation. Verify ownership for every object access in your application logic to prevent unauthorised data exposure.
Frequently asked questions
How do I distinguish between IDOR and broken access control?
IDOR is a specific type of broken access control where internal object references are exposed. All IDOR issues are broken access control, but not all broken access control issues are IDOR.
Can JWT tokens prevent IDOR vulnerabilities?
JWT tokens can carry user identity but do not automatically enforce resource ownership. You must still verify that the user in the JWT has permission to access the specific object requested.
Are UUIDs secure against IDOR attacks?
UUIDs are hard to guess but do not prevent IDOR if the application fails to check ownership. If an attacker obtains a valid UUID, they can access the resource without proper checks.
What is the difference between horizontal and vertical privilege escalation?
Horizontal escalation involves accessing resources of another user with the same privilege level. Vertical escalation involves accessing resources of a user with higher privileges, such as an admin.
How this guide was produced: written by the RedTeam Log editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
