Insecure Direct Object Reference (IDOR) is an access control flaw that lets an attacker view, modify, or delete data they should never be able to reach, simply by changing an identifier in a URL, API call, or form field. First cataloged by OWASP in 2007 and tracked today as CWE-639, IDOR remains one of the most common — and most damaging — vulnerabilities in modern web and API applications. Exploiting it doesn't require SQL injection, malware, or stolen credentials: an attacker changes ?invoice_id=10231 to ?invoice_id=10232 and, if the server trusts the client-supplied ID without verifying ownership, receives someone else's invoice. In 2019, First American Financial Corp exposed 885 million mortgage and title documents this way. In 2018, the USPS "Informed Visibility" API leaked account data on roughly 60 million users through the same class of bug. IDOR now sits inside OWASP's "Broken Access Control" category — the largest risk category in the 2021 Top 10 — and drives "Broken Object Level Authorization" (BOLA), ranked #1 in the OWASP API Security Top 10.
How Does an IDOR Vulnerability Actually Work?
IDOR happens when an application hands the client a direct, guessable reference to an internal object — a database row ID, a filename, a session token, an account number — and then fails to check whether the requesting user actually owns or is authorized to touch that specific object. A typical vulnerable endpoint looks like GET /api/v1/users/4471/documents/9902. If the backend runs SELECT * FROM documents WHERE id = 9902 without also checking WHERE owner_id = current_user.id, any authenticated user can iterate the id parameter — 9901, 9903, 9904 — and pull every other customer's documents. The flaw isn't in the authentication layer; the user is legitimately logged in. The flaw is that authorization is checked at the endpoint level ("can this role call this API?") but not at the object level ("can this specific user touch this specific record?"). Sequential integer IDs make this trivial to automate with a simple loop or a Burp Suite Intruder job; even non-sequential but predictable IDs (timestamps, incrementing UUIDv1, hashed emails) can often be brute-forced or enumerated within hours.
What's the Difference Between IDOR and Broken Access Control?
IDOR is a specific, well-documented subtype of the broader Broken Access Control category (CWE-284), distinguished by its reliance on manipulating a reference to a stored object rather than bypassing a role check, forging a JWT, or hitting an unprotected admin route. In the 2017 OWASP Top 10, IDOR was tracked as its own item, A5: "Broken Access Control" absorbed it along with A4 (Insecure Direct Object References) and A7 (Missing Function Level Access Control) into a single, consolidated category for the 2021 edition — which is why security teams now sometimes use "broken access control" and "IDOR" interchangeably even though IDOR is narrower. The distinction matters for remediation: fixing a missing role check might mean adding a middleware guard on a route, while fixing IDOR means adding ownership or entitlement checks to the query logic itself, on every single object-returning endpoint, not just the sensitive-looking ones.
What Are Real-World Examples of IDOR Breaches?
IDOR has caused some of the largest disclosed data exposures of the last decade, precisely because it scales linearly with object count and requires no special tooling to exploit. First American Financial Corp's May 2019 exposure of 885 million title insurance records (Social Security numbers, bank account numbers, wire transaction receipts) stemmed from sequential document IDs on an unauthenticated URL pattern. The USPS Informed Visibility API, reported in November 2018, let any logged-in user query the account details of any of the roughly 60 million other registered users by changing an account ID parameter. Peloton disclosed (patched May 2021, after researchers reported it in January) an API that let any user pull the private profile data — age, weight, gender, location — of any other Peloton member by referencing their user ID, regardless of that member's privacy settings. Parler's January 2021 incident, where researchers scraped roughly 70 terabytes of posts, videos, and location metadata, was enabled in part by predictable, sequential post IDs with no per-object authorization. T-Mobile's January 2023 breach, affecting 37 million accounts, involved an API abused in a similar object-enumeration pattern. Facebook has paid bug bounty awards for IDOR reports since at least 2013, including a $12,500 payout in 2015 for an IDOR that exposed private photos.
How Do You Detect IDOR Vulnerabilities Before Attackers Do?
Detecting IDOR requires testing authorization at the object level, not just the endpoint level, which is exactly why generic DAST scanners that crawl URLs and fuzz parameters routinely miss it — they see a 200 OK response and move on without knowing whether that data belonged to the authenticated user. Effective detection means authenticating as two separate low-privilege test accounts, capturing every object-returning request from account A, and replaying those same requests with account B's session token substituted in — swapping only the auth header, not the object ID — to see whether B receives A's data. This kind of differential testing catches IDOR in REST APIs, GraphQL resolvers (where a single query can traverse multiple object types and miss checks on nested fields), and even WebSocket message handlers. Static and reachability analysis of the codebase complements dynamic testing by flagging ORM calls (Model.find(params[:id]), db.query("... WHERE id = ?", id)) that lack an accompanying ownership predicate, and by tracing whether a user-controlled ID parameter actually reaches a database lookup with no scoping clause in between — turning a theoretical code smell into a confirmed, exploitable path.
How Do You Fix and Prevent IDOR?
Fixing IDOR means enforcing an object-level authorization check on every request that returns or modifies a specific resource, with a default-deny posture: the server verifies resource.owner_id == session.user_id (or checks a proper ACL/RBAC entry) before returning data, not after. Two additional controls reduce exposure even when a check is missed: replacing sequential integer IDs with random UUIDv4 or signed, opaque tokens makes enumeration computationally infeasible rather than a five-minute Burp Intruder job, and centralizing authorization logic in a single middleware or policy layer (rather than re-implementing ownership checks in every controller) prevents the "we forgot one endpoint" failure mode that caused the Peloton and USPS incidents. Rate limiting and anomaly detection on ID-parameter access patterns catch enumeration attempts in progress, and structured logging of every object access (who, which ID, granted or denied) turns a future incident response from guesswork into a fast, evidence-based investigation.
How Safeguard Helps
Safeguard's reachability analysis traces user-controlled parameters through your actual call graph to confirm whether an ID reaching a database or file lookup is missing an ownership check, so security teams triage confirmed, exploitable IDOR paths instead of chasing every :id route in the codebase. Griffin AI reviews pull requests for exactly this pattern — object-returning endpoints and ORM calls without a corresponding scoping clause — and flags them before merge, catching the kind of single-endpoint oversight that turned into the Peloton and USPS disclosures. Safeguard's SBOM generation and ingest give teams visibility into which API frameworks and ORMs are in use across every service, so authorization-layer gaps can be tracked at the component level, not just the endpoint level. For confirmed findings, Safeguard opens auto-fix PRs that add the missing ownership predicate or wire the endpoint into a centralized policy check, cutting remediation time from weeks of manual code review to a single reviewed merge.