IDOR (Insecure Direct Object Reference)

An insecure direct object reference is a specific and very common form of broken access control. It occurs when an application takes an identifier supplied by the user, such as a record number in a URL or an account identifier in an API request, and uses it to fetch or change data without first confirming that the user is allowed to act on that particular object.

The classic example is a web address that ends with a document or account identifier. If the application returns whatever record matches that identifier without checking ownership, an attacker can simply increment or change the value and page through data belonging to other users. The same pattern appears in APIs, where an identifier in a request body or header controls which resource is returned, and in file-download features that accept a filename or path.

IDOR is dangerous because it is easy to exploit, requires no special tooling, and often exposes sensitive personal or financial data at scale. An attacker does not need to defeat authentication; they log in as a legitimate low-privilege user and then reach data they were never meant to see. Because the requests look valid, IDOR exploitation frequently leaves little trace in logs.

Automated scanners are poor at detecting IDOR because the tool cannot know which records a given user should legitimately access. Determining that record 1001 belongs to a different customer, and that the current user should be denied it, requires understanding the application’s ownership model, which is why manual testing is the reliable way to find these flaws.

The fix is to enforce an authorisation check on every object access, verifying that the authenticated user owns or is permitted to use the specific resource being requested, rather than trusting the identifier itself. Using indirect references that are unpredictable and scoped to a session can add defence in depth, but the essential control is a server-side ownership check on every request. Predictable identifiers alone are not the vulnerability; the missing check is.

IDOR is frequently discovered in APIs, where identifiers are passed in requests and where developers sometimes assume the client will only ever request its own data. That assumption fails the moment an attacker inspects and replays the traffic. The reliable defence is the same everywhere: verify on the server, for every request, that the authenticated user is authorised to act on the specific object named, rather than trusting the identifier or the client to enforce the boundary.

IDOR is a priority target in any web application or API penetration test because it maps directly to data-breach risk and regulatory exposure. Precursor tests object references across roles and accounts to confirm that users can only reach the data they own, and reports each reference that can be manipulated.