Insecure Direct Object References (IDOR) is a type of web security vulnerability that occurs when an application exposes references to internal objects, such as files, database records, or other resources, without proper authorization checks. This allows an attacker to manipulate these references to access unauthorized data.

How IDOR Works

IDOR typically arises when user input is directly used to access resources without validating that the user is authorized to view or manipulate those resources. If an application allows users to modify parameters in URLs or forms (e.g., user IDs, document IDs) without proper checks, an attacker can exploit this by changing those parameters to access data belonging to other users.

Example of IDOR

Scenario

Consider a web application that allows users to view their profile details. The application retrieves user data based on a user ID provided in the URL:

GET <https://example.com/profile?id=123>

This URL retrieves the profile for the user with ID 123. If the application does not check whether the logged-in user is authorized to access that profile, an attacker could manipulate the id parameter.

Exploit

If an attacker is logged in as a different user (e.g., User 456) and changes the URL to:

GET <https://example.com/profile?id=124>

The application might return the profile for User 124, which they are not authorized to access. This can lead to data exposure, such as personal information, account details, or sensitive data.

Consequences of IDOR

• Data Exposure: Attackers can gain unauthorized access to sensitive information belonging to other users.
• Data Modification: If the application allows updates (e.g., editing a profile), attackers could modify someone else's data.
• Account Compromise: In some cases, IDOR can lead to account takeover if sensitive data (like passwords) is exposed.

Prevention Techniques

1. Authorization Checks: Always verify that the user has permission to access the requested resource. This should be done server-side and not solely based on user input.

2. Use Indirect References: Instead of exposing direct references (like database IDs), use indirect references such as tokens or hashed values that map to the actual objects on the server.

   • Example: Instead of using user IDs in the URL, use a unique token:

     GET <https://example.com/profile?token=abc123xyz>
     
     

3. Limit User Access: Design the application to limit user access to only their data. Ensure that even if an attacker changes parameters, they cannot access unauthorized resources.