Insecure Direct Object Reference (IDOR)
What is Insecure Direct Object Reference (IDOR)?
Insecure Direct Object Reference (IDOR)An access-control flaw where an application exposes references to internal objects and lets a user change them to access data that does not belong to them.
IDOR occurs when an endpoint uses a user-supplied identifier (numeric ID, UUID, filename, account number) to fetch or modify an object without verifying that the caller is authorized for that specific object. Sequential IDs and predictable references make exploitation trivial, but even UUIDs are unsafe if any user can guess or leak them. IDOR is one of the most common bug-bounty findings and a leading cause of multi-tenant data breaches. Fixes include enforcing per-request ownership checks on the server, scoping database queries to the current user/tenant, using indirect references (opaque per-session maps), and adding automated tests for horizontal access.
● Examples
- 01
Changing /invoices/1042 to /invoices/1043 and reading another customer's invoice.
- 02
Editing a profile picture URL parameter to overwrite another user's avatar.
● Frequently asked questions
What is Insecure Direct Object Reference (IDOR)?
An access-control flaw where an application exposes references to internal objects and lets a user change them to access data that does not belong to them. It belongs to the Vulnerabilities category of cybersecurity.
What does Insecure Direct Object Reference (IDOR) mean?
An access-control flaw where an application exposes references to internal objects and lets a user change them to access data that does not belong to them.
How do you defend against Insecure Direct Object Reference (IDOR)?
Defences for Insecure Direct Object Reference (IDOR) typically combine technical controls and operational practices, as detailed in the full definition above.
What are other names for Insecure Direct Object Reference (IDOR)?
Common alternative names include: IDOR, Direct object reference vulnerability.