Insecure Direct Object References (IDOR)

Insecure Direct Object References (IDOR)

IDOR occurs when an application provides direct access to an object using a user input. IDOR allows attackers to bypass authorization mechanisms to access information/resources directly by manipulating the value of a parameter used to point to that resource/object.

Attackers can use IDOR to access resources of another user (Files, PII, etc.) or functionality/privileges of another user (Admin, Moderator, etc.).

This vulnerability is caused by the fact that the application does not validate the user input and uses it to retrieve an object/resource without performing sufficient authorization checks.

Impact

• Unauthorized access of resources.

  • Viewing sensitive user information

  • Viewing files that are private to the user

  • Downloading invoices from another user

• Unauthorized data manipulation.

  • This is not just limited to user data, it can also include other objects such as:

    • Videos in a video streaming site. Manipulating the video thumbnail.

• Data leaks.

• Confidentiality breach (user PII, invoices, private documents)

• Privilege escalation (gaining admin-level access)

• Account takeover (resetting passwords for other users)

Test Objectives

• Identify points where object references may occur.

• Assess the access control measures and if they’re vulnerable to IDOR.

Enumeration

• Understand how the application works

  • How does it fetch data?

  • How does it create new data?

  • How does it delete or modify data?

  • Is the information being leaked or is this information available to everybody that’s using the app?

  • Allways test the functionality of the application and observe the responses if it leaks useful information.

    • Test password reset function. Does the application displays the User ID on the response?

    • Test Email/Username/Name/Address update function.

    • Can you send those parameters you saw on the response to the server? Will the server accept those additional parameters?

• Look for endpoints that can be targeted using IDOR

  • Unindexed endpoints from robots.txt file

  • Hidden endpoints found in JavaScript files

• Look for any numerical IDs in the request

• Map out all locations in the application where user input is used to reference objects directly

  • URL as part of a query string

    • https://contoso.com/home.php?account=1001

    • The value of these parameters can be an encoded/hashed value.

      • https://contoso.com/home.php?account=MTAwMQ

  • Body of a request

    • { "user_id": "1234" }

  • Header

    • X-User-ID: 1234

  • Cookie

    • session_id=xyz123

  • Email/Usernames (if email-based identification is used)

  • File Identifiers (e.g., /download/123.pdf → /download/122.pdf)

• Applications may use UUIDs instead of IDs

  • Look for parts of application where these UUIDs can be leaked

    • Image source of the profile picture of a user

    • Report user function where a user ID might be included in the request

How to Test for IDOR

• Modify the value of the parameter used to reference objects and check whether it is possible to retrieve objects/resources belonging to other users (user_id, order_id, doc_id).

• Test endpoints using different HTTP Methods (GET, POST, PUT, DELETE)

• Try using another user's credentials in API requests

• Use Burp Suite's Autorize extension to detect access control issues

• Check if deleting, modifying, or accessing data affects other users

• Automate testing using ffuf, wfuzz, and Burp Suite Intruder

  • Intercept the request

  • Try to brute force the IDs to enumerate user and find user data

  • Use a number that’s around the number of the valid user ID then test using a larger set of IDs

• Check Access Control

  • Try requests as an unauthenticated user

  • Test with a lower-privileged user

  • Try modifying another user's data

  • Try resetting another user’s password

    • If you can trigger a reset email for another user, that’s a critical IDOR.

  • See if elevated access is possible (e.g., normal user accessing an admin function)

    • If you can upgrade another user’s role, that's a critical IDOR.

    • Look for user update function and check the request to see if you can modify user roles

  • Order / Transaction manipulation

  • File / Document Access

• Monitor responses

  • Look for status code differences (200 vs. 403)

  • Check error messages (e.g., "User Not Authorized" vs. unintended data disclosure)

  • Observe response size changes

  • Look for leaked user details (emails, PII, internal data)

Best Practice for Testing

• Create at least two or more user account that contains different objects and functions.

• Example:

  • Each users has different account information, purchase information, private message, etc.

  • Users with different privileges (Admin, User, Moderator, etc.)

Examples

• The Value of a Parameter Is Used Directly to Retrieve a Database Record

  • http://foo.bar/somepage?invoice=12345

• The Value of a Parameter Is Used Directly to Perform an Operation in the System

  • http://foo.bar/changepassword?user=someuser

• The Value of a Parameter Is Used Directly to Retrieve a File System Resource

  • http://foo.bar/showImage?img=img00011

• The Value of a Parameter Is Used Directly to Access Application Functionality

  • http://foo.bar/accessPage?menuitem=12

Bypasses

If you get an error accessing another data you can try the following:

• Adding a / after the request: /api/user/1/

• Test directory traversal: /api/user/1/../1

• Access the endpoint and see if it dumps all the users: /api/user/

• Try a different HTTP method: POST /api/user/1

Broken Acccess Controls

• Unprotected functionality

  • Can you access endpoints that should only be accessed by admins?

• Parameter-based access control methods

  • Can you access objects/resources from other users by changing the value of a parameter?

• Broken access control resulting from platform misconfiguration

  • Can you access restricted resources by changing/adding headers?

    • Change HTTP Methods (POST → GET)

    • Add headers: X-Original-URL / X-Rewrite-URL

• Broken access control resulting from URL-matching discrepancies

  • Can you access restricted resources by changing the URL format/capitalization.

    • /admin/deleteUser → /ADMIN/DELETEUSER

    • /admin/deleteUser → /admin/deleteUser.anything

    • /admin/deleteUser → /admin/deleteUser/

• Horizontal to Vertical privesc

  • Try to access a user with admin privileges

• Access control vulnerabilities in multi-step processes

  • Look for functions that requires multi-step process

    • Forms that that allows you to review/confirm changes. You might be able to access the functionality of that endpoint on the review page.

• Referer-based access control

  • Some sub-pages are restricted and can only be access if the referer header contains the parent page.

  • Change/add the Referer header with the value of the parent page of the restricted sub-pages to access those pages and functionality.

    GET /admin-roles?username=wiener&action=upgrade HTTP/1.1
    Host: acme.net
    Referer: <https://acme.net/admin>
    Cookie: session=User0001

• Location-based access control

References / Resources:

• 4.5.4 Testing for Insecure Direct Object References: WSTG - Stable | OWASP Foundation

• PortSwigger: Insecure direct object references (IDOR) | Web Security Academy

• PortSwigger: Access control vulnerabilities and privilege escalation | Web Security Academy

• OWASP Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html