What is an IDOR (insecure direct object reference)?
Last reviewed June 2, 2026
An insecure direct object reference (IDOR) is an access-control flaw where an application exposes a reference to an object, like a record ID in a URL, and fails to verify the user is authorized to access it. By changing the identifier, an attacker reaches other users' data. The fix is enforcing authorization on every object access, not obscuring the IDs.
What an IDOR is
An insecure direct object reference, tracked as CWE-639 (Authorization Bypass Through User-Controlled Key), occurs when an application uses a user-supplied identifier to look up an object directly but does not check whether the requesting user is allowed to access that specific object. The reference itself is fine; the missing authorization check is the flaw.
IDOR is a leading example of broken access control, which sits at the top of the OWASP Top 10. It is common because developers often verify that a user is authenticated but forget to verify that they own or may access the particular record being requested.
How the attack works
Suppose viewing an invoice uses a URL like /invoices/1004 and the application returns invoice 1004 to any logged-in user. An attacker simply changes the number to /invoices/1005 and receives a different customer's invoice, because the server never checked that the invoice belongs to the requesting account.
The same pattern applies to numeric IDs, usernames, filenames, and even API object keys. Switching to unguessable identifiers like UUIDs raises the difficulty of guessing, but it does not fix the vulnerability: if there is still no authorization check, a leaked or enumerated identifier grants access.
Real-world impact
- Horizontal access to other users' records, such as orders, messages, or profiles.
- Bulk data exposure when identifiers are sequential and easily enumerated.
- Unauthorized modification or deletion when write endpoints share the flaw.
- Privacy and compliance violations from exposing personal or regulated data.
How to prevent it
The durable fix is authorization, not obscurity: every direct object reference must be backed by a check that the requester is entitled to that object.
- Enforce object-level authorization on the server for every request: confirm the current user may access the specific object before returning or modifying it.
- Centralize access-control checks so they cannot be forgotten on individual endpoints.
- Do not rely on unguessable IDs as a security control; treat them as defense in depth only.
- Scope queries to the authenticated user (for example WHERE owner_id = current_user) so a mismatched ID returns nothing.
- Test for IDOR by attempting to access objects belonging to other accounts.
Keep exploring
- CWE-639: Authorization Bypass Through User-Controlled KeyThe MITRE weakness entry IDOR maps to.
- What is privilege escalation?IDOR is a common route to horizontal escalation.
- What is path traversal?Another flaw driven by attacker-chosen references.
- Browse the CWE directoryExplore the full catalog of weakness types.
- What is broken access control?OWASP A01: acting outside your permissions.
Frequently asked questions
- What is an IDOR in simple terms?
- It is when you can see someone else's data just by changing an ID in the URL or request, because the app does not check that the data actually belongs to you.
- Does using UUIDs fix IDOR?
- No. UUIDs make identifiers harder to guess but do not add authorization. If the server still does not verify access, a leaked or enumerated UUID exposes the object. Proper access-control checks are the real fix.
- Is IDOR the same as broken access control?
- IDOR is a specific type of broken access control, focused on object-level authorization. Broken access control is the broader category that also includes missing function-level checks and privilege issues.
- Which CWE covers IDOR?
- IDOR maps to CWE-639, Authorization Bypass Through User-Controlled Key. It falls under the broader broken-access-control family.
