Insecure Direct Object Reference (IDOR)

Key Takeaways

• Insecure direct object reference (IDOR) lets a user access records or actions belonging to others by manipulating an identifier in a request.
• It is a form of broken access control, caused by a missing check on whether the requester actually owns the resource.
• A simple IDOR attack, incrementing an ID to read other users’ data, is a textbook case of horizontal privilege escalation.
• Automated scanners struggle to detect IDOR because a successful exploit looks like a normal, well-formed response, not an error.
• The core fix is a per-request, server-side authorization check for the current user, backed by unpredictable identifiers and logic-aware testing.

What Insecure Direct Object Reference Means

Insecure direct object reference, usually shortened to IDOR, is an access control flaw that lets a user reach data or actions belonging to someone else. It happens when an application uses a value from the request, such as an ID in a URL, to fetch a record without checking whether the requester is allowed to see it.

The reference itself is not the problem; applications routinely expose identifiers in URLs and API calls. The vulnerability is the missing check: the application trusts that if you can name a record, you are entitled to it.

An IDOR vulnerability is a specific form of broken access control, and one of the most prevalent flaws in modern web and API-driven applications.

What an Attacker Can Do With an IDOR Vulnerability

Consider an application where viewing your invoice loads a URL ending in a number, say 4012. You are allowed to see your own invoice, so the request succeeds.

An attacker changes the number, requesting 4011, then 4013, then thousands of values automatically. If the application returns each record without confirming ownership, the attacker reads every customer’s invoices, one incremented ID at a time. This is a classic IDOR attack, and textbook horizontal privilege escalation: a user reaching data that belongs to others at the same permission level.

The damage is not limited to reading. The same missing check on an update or delete action lets an attacker modify or remove other people’s records. Change the ID on a “reset password” or “update email” endpoint and the flaw can escalate from data exposure to full account takeover.

Why IDOR Vulnerabilities Are So Easy to Miss in Testing

IDOR is notoriously hard to catch with automated tools, and the reason is fundamental. A scanner can see that a request contains an ID and that changing it returns data. What it cannot judge is whether that data is supposed to be off-limits to this user, which requires understanding the application’s intended permissions.

To a pattern-matching tool, a successful response looks like success. There is no malformed input, no error, no signature to flag. The request is perfectly well-formed; it simply should not have been allowed.

That is why IDOR survives most standard reviews and surfaces mainly through testing that reasons about roles and ownership. It is the kind of flaw that platforms building a persistent model of an application’s permissions and business logic, an approach used by AI pentesting tools such as Novee, are designed to catch.

How to Reduce IDOR Risk in Your Application

The single most important defense is a server-side authorization check on every request that accesses a specific object. Never assume that holding an identifier implies permission: on every access, ask whether this authenticated user may touch this exact record.

Design choices help too. Unpredictable identifiers such as UUIDs, rather than sequential numbers, make enumeration harder, though that is mitigation, not a substitute for authorization checks. Scoping queries to the current user’s data at the database layer stops the application from ever returning someone else’s record.

Testing has to match the flaw. Because IDOR hinges on logic rather than signatures, combine access-control-aware web application security testing tools with human review, and understand where automated testing ends and adversarial testing begins, a distinction covered in this comparison of pentesting versus red teaming.

FAQ