Cybersecurity glossary
What is Insecure Direct Object Reference (IDOR)?
Learn what Insecure Direct Object Reference (IDOR) is, how attackers access other users’ objects by changing IDs, how it relates to broken access control, and how to prevent it with authorization checks.
Definition
Insecure Direct Object Reference (IDOR) is an access-control weakness in which an application exposes internal object identifiers and fails to verify that the authenticated requester is authorized to access the corresponding object, allowing attackers to read or modify other users’ data by changing IDs.
Why IDOR matters
Authentication answers “who are you?” Authorization answers “are you allowed to touch this?” Insecure Direct Object Reference (IDOR) appears when applications trust an object identifier from the client—/orders/54821, /api/docs/19, accountId=88—without proving the requester owns or may access that object.
IDORs are devastating because they are easy to automate and often bypass fancy UI protections. A mobile app may hide other users’ IDs while the API happily returns them to anyone with a valid session.
This glossary defines the concept. The vulnerability page covers deeper exploitation patterns.
How IDOR works
Authenticate as a low-privilege user
Obtain a normal session or API token for an ordinary account.
Capture an object reference
Note IDs in URLs, JSON bodies, or mobile API calls for resources the user legitimately can access.
Substitute another object ID
Change numeric IDs, UUIDs, or filenames to values belonging to other users or tenants.
Observe unauthorized success
If the server returns or modifies the object without an ownership check, IDOR is confirmed.
Enumerate at scale
Scripts walk ID spaces or scrape references to mass-exfiltrate data.
Expand to write actions
Apply the same swap to update, delete, share, and approve endpoints.
Common IDOR patterns
Horizontal access
User A reads User B’s profile, messages, invoices, or files at the same privilege tier.
Vertical spillover
A regular user reaches admin-only objects by ID when role checks are missing.
Multi-tenant leakage
Tenant A’s API keys open tenant B’s records because queries filter only by object ID.
Function-level variants
Export, share, or preview endpoints skip the checks present on the primary GET route.
Why “obscure IDs” are not enough
| Control | Verdict |
|---|---|
| Sequential integers | Easy to enumerate; high IDOR risk without authz |
| UUIDs / random IDs | Harder to guess; still require per-object authorization |
| UI hiding of IDs | Not a security boundary; APIs remain callable |
| Server-side ownership checks | Required fix for IDOR |
Prevention checklist
- Authorize every object read/write/delete with the current principal and tenant context.
- Prefer queries scoped by user/tenant that cannot return cross-owner rows even if IDs are guessed.
- Centralize authorization helpers so each endpoint does not reinvent incomplete checks.
- Test horizontal access with two users in automated integration tests.
- Review secondary flows: exports, previews, webhooks, batch jobs, and share links.
- Log authorization denials on sensitive objects for detection and tuning.
- Do not treat presence of a valid session as permission for arbitrary IDs.
- Align API gateway controls with application object-level checks—gateways alone are rarely enough.
The practical takeaway
IDOR is missing object-level authorization when clients supply object references. Changing an ID should never be enough to reach another user’s data.
Fix it with explicit, server-side authorization on every object operation. Random identifiers help a little; only real access checks close the vulnerability.
Related security terms
Broken Authentication
Identity failures that are distinct from—but often paired with—authorization bugs like IDOR.
Privilege Escalation
Broader elevation of access; IDOR is a common horizontal form.
API Abuse
APIs are a frequent IDOR surface when object IDs are guessable or enumerable.
Insecure Direct Object Reference (IDOR)
Vulnerability-focused deep dive on IDOR exploitation and remediation.
Frequently asked questions
What is IDOR in simple terms?
IDOR happens when a website uses an ID like ?invoice=1221 and does not check whether that invoice belongs to you. Changing the number may show someone else’s invoice.
Is IDOR the same as broken access control?
IDOR is a common form of broken access control focused on direct references to objects. Broken access control is the broader category.
What is BOLA?
Broken Object Level Authorization is the API Security Top 10 name for the same class of failures: missing per-object authorization checks.
Do random UUIDs fix IDOR?
Harder-to-guess IDs reduce casual enumeration but are not authorization. Anyone who obtains a UUID still needs a server-side ownership check.
Where does IDOR appear most?
APIs that fetch records by ID, file downloads, export jobs, password-reset tokens used as references, and multi-tenant SaaS object routes.
How do you prevent IDOR?
On every object access, authorize that the current principal may perform the requested action on that specific object. Prefer server-side lookups scoped by user/tenant.
Is IDOR only a read issue?
No. Attackers also change IDs on update, delete, share, and approve operations to modify or destroy other users’ objects.
References
Explore authoritative guidance and frameworks related to insecure direct object reference (idor).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.