Insecure Direct Object References let one user peek into – or tamper with – another user’s data simply by changing a number or an ID in a URL or API request. It sounds almost too simple to be dangerous, but IDOR remains one of the most common and most damaging flaws found during any serious website security scanning effort, precisely because it doesn’t require exploit code, just curiosity and a browser’s address bar.
This article walks through what IDOR actually is, how it shows up in real applications, why it keeps slipping past code review, and what concrete steps close the gap.
What an Insecure Direct Object Reference actually is
An IDOR happens when an application exposes a reference to an internal object – a database row, a file, an account – and lets a user change that reference without checking whether they’re actually allowed to access the resource it points to.
The classic example: a logged-in user views their invoice at /invoices/4521. They change the number to 4522 and suddenly see someone else’s invoice, full name, address, and amount billed. Nothing was “hacked” in the traditional sense – the server just never asked “does this session actually own object 4522?”
IDOR falls under the OWASP Broken Access Control category, which has consistently ranked as one of the most frequently found issues in real-world applications. It’s worth reading through the wider access control landscape if this is new territory, since IDOR is rarely the only access control gap on a site.
Why IDOR is so easy to introduce and so easy to miss
Developers usually build the “happy path” first: a user logs in, requests their own data, gets it back correctly. Authorization checks tend to get added later, or assumed to be handled somewhere else in the stack – middleware, a framework decorator, an API gateway. That assumption is where things break down.
A few patterns that reliably produce IDOR bugs:
Sequential or predictable IDs. Auto-incrementing primary keys used directly in URLs or JSON payloads make guessing trivial. Object 1000 exists, so does 999 and 1001.
Client-trusted identifiers. An API endpoint that reads a user_id field from the request body instead of deriving it from the authenticated session token. The client can send any ID it wants.
Authorization checked at the UI layer only. The front end hides a “delete” button for resources you don’t own, but the backend API endpoint that actually performs the delete never verifies ownership. Anyone with a browser console or a tool like Burp Suite can call the endpoint directly.
Multi-step workflows. Access is checked on step one of a process (say, opening a support ticket) but not re-verified on step three (downloading an attachment), because the developer assumed the session context carried through correctly.
This is also where a common myth needs busting: many teams believe that if an endpoint requires authentication, it’s safe. Authentication only proves who you are – it says nothing about what you’re allowed to touch. A perfectly authenticated, logged-in user can still commit IDOR if the object-level authorization check is missing. Security professionals sometimes call this the difference between “AuthN” and “AuthZ,” and conflating them is the single biggest reason IDOR bugs survive into production.
Real-world impact: it’s rarely just one record
IDOR bugs are attractive to attackers because they scale. A single missing ownership check on an invoice endpoint doesn’t expose one invoice – it exposes every invoice in the system, one increment at a time. Automated scripts can iterate through thousands of IDs in minutes.
Depending on the object type, the consequences vary sharply:
Reading another user’s profile data or order history is a privacy and often a GDPR compliance problem, since personal data is being disclosed without a lawful basis.
Modifying someone else’s data – changing a shipping address, updating account settings, or altering a password reset token – moves from data exposure into account takeover territory.
Deleting or overwriting objects that belong to other users can cause direct business damage, from lost customer records to corrupted financial data.
Because the flaw sits at the application logic level rather than in a library or a server configuration, it’s invisible to scanners that only check for known CVEs or outdated software versions. Effective detection needs testing that actually exercises the application’s business logic across multiple user contexts – part of why a proper security posture audit looks well beyond patch levels.
Finding IDOR before an attacker does
A practical testing approach follows these steps:
Map every endpoint that accepts an identifier – in the URL path, query string, request body, or headers.
Create two test accounts with clearly separated data (Account A and Account B).
Log in as Account A, capture the requests used to view or modify its own objects.
Replay those same requests while authenticated as Account A, but swap in Account B’s object IDs.
Check whether the response returns Account B’s data, allows modification, or simply errors out with a proper 403/404. A working access control check should reject the request; anything else is a finding.
Repeat across every object type: profiles, orders, messages, uploaded files, API tokens, admin actions.
This is manual, methodical work, which is exactly why it complements rather than replaces automated coverage – tools are excellent at catching injection flaws, missing headers, and misconfigurations at scale, while targeted logic testing catches the object-level gaps. Understanding where each approach is strongest is covered in more depth when comparing automated scanning against manual penetration testing.
Fixing IDOR at the code level
The fix is conceptually simple even though it takes discipline to apply consistently:
Enforce object-level authorization on every request, server-side, no exceptions for “internal” or “admin” endpoints. Check that the authenticated session actually owns or has explicit permission for the requested object before returning or modifying anything.
Avoid trusting any identifier supplied by the client for determining whose data to act on. Derive the acting user from the verified session or token, never from a field the client can edit.
Use indirect references where practical – a UUID or a per-user mapping token instead of a sequential database ID – which won’t stop a determined attacker but removes the trivial guess-and-check attack.
Apply the same authorization middleware consistently across REST and GraphQL resolvers alike, since GraphQL’s flexible query structure makes it easy to forget a check on a nested field. This is a large enough topic on its own, and worth reviewing alongside general API security best practices.
Log and alert on authorization failures. A spike in 403 responses against sequential IDs is a strong signal someone is enumerating objects.
Frequently asked questions
Is IDOR the same as broken access control?
IDOR is a specific, very common type of broken access control. Broken access control is the broader OWASP category covering any failure to properly restrict what authenticated or unauthenticated users can do; IDOR specifically refers to manipulating object references to reach unauthorized data.
Can automated scanners detect IDOR reliably?
Partially. Scanners can flag suspicious patterns – sequential IDs, inconsistent response codes across similar requests – but confirming true IDOR usually requires authenticated, multi-account testing that mirrors real attacker behavior, since it depends on business logic rather than a signature.
Does using UUIDs instead of sequential IDs solve the problem?
It reduces the risk of casual enumeration but does not fix the underlying issue. Without a proper server-side ownership check, a UUID that leaks through a log file, referrer header, or shared link is just as exploitable as a guessable integer.
IDOR persists because it’s a logic failure, not a missing patch – no software update fixes a check that was never written. Treat every endpoint that accepts an identifier as a candidate for an ownership check, test it with two accounts instead of one, and the majority of these bugs never make it to production.