What is IDOR (Insecure Direct Object Reference)?

IDOR occurs when an application exposes internal object references like database IDs without proper authorization checks, allowing attackers to access other users' data by manipulating identifiers.

What is an Insecure Direct Object Reference?

IDOR is an access control vulnerability where applications use user-supplied input to directly reference internal objects like database records, files, or directories without verifying authorization. Attackers manipulate identifiers (e.g., changing user_id=123 to user_id=124) to access resources belonging to other users.

How do attackers exploit IDOR vulnerabilities?

Attackers enumerate predictable identifiers like sequential database IDs, UUIDs, or filenames in API endpoints and URL parameters. By modifying these references in requests, they access other users' profiles, documents, transactions, or private data. Automated tools can rapidly iterate through thousands of potential identifiers.

What is the impact of IDOR vulnerabilities?

IDOR can lead to unauthorized data access, account takeover, sensitive information disclosure, data modification, and privilege escalation. In healthcare or financial applications, IDOR can expose medical records or financial data, resulting in regulatory violations under HIPAA, GDPR, or PCI DSS.

How do you prevent IDOR vulnerabilities?

Prevention requires implementing server-side authorization checks on every object access, using indirect reference maps that translate user-facing tokens to internal IDs, validating that the authenticated user owns or has permission to access the requested resource, and applying the principle of least privilege consistently.

What is the difference between IDOR and broken access control?

IDOR is a specific type of broken access control vulnerability focused on direct object reference manipulation. Broken access control is the broader category (OWASP A01:2021) encompassing IDOR along with privilege escalation, forced browsing, CORS misconfigurations, and other authorization bypass techniques.

How do you test for IDOR?

Testing involves creating multiple user accounts, capturing requests containing object references, and swapping identifiers between accounts. Testers systematically modify IDs in URLs, request bodies, headers, and cookies. Both horizontal (same-role) and vertical (cross-role) access attempts should be tested across all API endpoints.

Are UUIDs sufficient to prevent IDOR?

UUIDs reduce enumeration risk but do not prevent IDOR. While sequential IDs are trivially guessable, UUIDs can leak through logs, URLs, API responses, or client-side code. Server-side authorization checks remain essential regardless of identifier format. UUIDs are defense-in-depth, not a primary control.

What are common locations where IDOR occurs?

IDOR commonly appears in REST API endpoints with resource IDs, file download endpoints, user profile pages, order history pages, invoice access URLs, document management systems, messaging features, and any endpoint where object identifiers are passed as parameters without corresponding authorization validation.