Insecure direct object references, commonly abbreviated IDOR, represent a common but often overlooked application security vulnerability class, where an application exposes internal object references – database IDs, file paths – without adequately verifying that the actual requesting user has authorization to access that specific referenced object.
How IDOR Vulnerabilities Work
IDOR vulnerabilities occur when an application uses a predictable or guessable identifier to reference a specific object – a user account, document, or order record – and fails to properly verify that the actual current requesting user has legitimate authorization to access that specific referenced object. Simply checking whether the object exists is not the same thing.
A simple example involves an URL parameter referencing an account ID – if an application serves account information purely based on the ID provided in the request, without verifying that the requesting user owns or has legitimate authorization to view that specific account, an attacker can access other users’ data simply by incrementing or otherwise guessing a different valid ID value.
Why IDOR Persists Despite Being Well-Understood
IDOR vulnerabilities persist in modern applications despite being a well-documented, long-understood vulnerability class, largely because authorization checks are easy to overlook during rapid development, particularly when a developer correctly implements authentication – verifying who a user is – while forgetting the separate, equally necessary step of authorization – verifying what that specific authenticated user is allowed to access.
The Difference Between Authentication and Authorization Failures
IDOR represents an authorization failure, not an authentication failure – the attacker in an IDOR scenario is often a properly authenticated, legitimate user of the application, simply accessing objects beyond their own actual legitimate authorization scope. That is exactly why IDOR often evades security testing focused primarily on authentication bypass. The real gap sits in authorization boundary testing, not authentication testing.
Why Automated Scanning Often Misses IDOR
Automated vulnerability scanners often struggle to reliably detect IDOR vulnerabilities. Identifying them requires understanding actual application-specific business logic and legitimate authorization boundaries, a contextual understanding that generic automated scanning tools cannot easily replicate without specific configuration and manual security testing expertise.
Effective Prevention Through Consistent Authorization Checks
Preventing IDOR requires consistently verifying authorization on every single object access, not purely at initial authentication. It also helps to use indirect object references, such as session-specific mapping tokens, instead of exposing predictable direct database identifiers in user-facing URLs and API parameters, wherever that approach is practical to implement.
Why Code Review Catches IDOR Better Than Automated Tools
Given automated scanning’s limitations detecting IDOR, thorough manual code review focused specifically on authorization logic remains one of the more effective detection methods. A careful human reviewer can evaluate whether authorization checks are consistently and correctly applied across all the various relevant application code paths.
Building Systematic Authorization Testing Into Development Practice
Organizations should build systematic authorization testing into their standard development and security testing practice, treating IDOR as a distinct vulnerability category deserving dedicated testing attention, rather than assuming general security testing will automatically and adequately catch this common but easily overlooked vulnerability class on its own.
Why IDOR in APIs Is a Bigger Problem Than IDOR in a Web Page
An IDOR flaw in a traditional web page is bad, but it is at least somewhat self-limiting – a human attacker has to click through URLs one at a time, or write custom tooling to automate it. The same flaw in a REST or GraphQL API is considerably worse in practice, because the structured, predictable format that makes APIs easy to build against also makes them trivially easy to enumerate at scale. A script that increments an order ID parameter against an API endpoint can pull thousands of other customers’ records in minutes, with no rate limiting or browser-driven pacing slowing it down the way clicking through a web interface naturally would. This is part of why IDOR, sometimes now more specifically labeled broken object level authorization in API security contexts, gets called out as its own distinct top risk category in API-specific security guidance, separate from the broader web application vulnerability list it originated from.
A Realistic Fix Pattern: Indirect References Done Right
Swapping sequential database IDs for UUIDs is a common first response to an IDOR finding, and it is worth being clear about what it actually accomplishes – it makes IDs unguessable, which blocks casual enumeration, but it does nothing to stop an authenticated attacker who already has a valid ID for an object they are not authorized to access, whether obtained through their own legitimate use of the system or leaked some other way. The fix that actually closes the gap is an authorization check on every single access to every object, verifying the requesting user’s relationship to that specific object regardless of whether the ID itself is guessable, with unguessable IDs treated as a useful additional layer rather than a substitute for that authorization check.
Testing for IDOR Requires Two Real Accounts, Not One
A surprisingly common gap in internal security testing is that it gets performed with a single test account, which structurally cannot reveal an IDOR flaw at all – there is nothing to cross-reference against. Effective IDOR testing requires at least two accounts at the same privilege level, deliberately attempting to access one account’s objects using the other account’s session, a simple but frequently skipped step that a single-account testing habit will never surface on its own, regardless of how much other testing effort is applied around it.