Insecure Direct Object References (IDOR)

SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration
SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration

All Entries

Scan Your Site

Check your website for this issue

Run an automated scan and see whether your site is affected — with plain-language findings and fixes.

Start Scanning
Category Broken Access Control
Typical Severity High
OWASP A01:2021 – Broken Access Control
CWE CWE-639 – Authorization Bypass Through User-Controlled Key
Also known as IDOR, Object-Level Authorization Flaw, Broken Object-Level Authorization (BOLA)
Affected systems Web applications, REST APIs, mobile backends — any system that uses predictable identifiers to reference server-side objects

Overview

Insecure Direct Object Reference (IDOR) occurs when an application uses a client-supplied identifier — an integer ID, UUID, filename, or similar value — to look up a server-side object without first verifying that the requesting user is authorized to access that specific object. Because the check is missing or insufficient, an attacker can substitute a different identifier and retrieve or manipulate data belonging to another user or entity.

IDOR is not an injection vulnerability; it is purely an access control failure. It is listed under OWASP A01:2021 – Broken Access Control, the most prevalent web application security risk category, and is formally classified as CWE-639. In the API security context, the same pattern is often called Broken Object-Level Authorization (BOLA), highlighted as API1:2023 in the OWASP API Security Top 10.

How it works

The vulnerability arises when a three-step pattern is broken at step three: (1) the application stores objects with identifiers, (2) it exposes those identifiers to clients in URLs, request bodies, or cookies, and (3) it fails to verify ownership or permission before serving or modifying the referenced object.

  • Predictable sequential IDs: A URL such as GET /invoices/10042 reveals that other invoices likely exist at /invoices/10041, /invoices/10043, and so on. An attacker iterates over these values (a technique called IDOR enumeration or horizontal privilege escalation).
  • Opaque but exposed identifiers: Even UUIDs or hashed IDs are insufficient substitutes for authorization checks. If the server does not verify the caller's rights, the obscurity of the identifier provides only weak security-by-obscurity protection.
  • Vertical privilege escalation: IDOR can also be exploited to access objects at a higher privilege level — e.g., substituting a regular user's account ID with an admin account ID in a management endpoint.
  • POST/PUT/DELETE targets: Write operations are equally affected. An attacker may modify or delete another user's record by supplying its identifier in the request body or path.
  • Indirect references in parameters: File download endpoints (/download?file=report_user123.pdf), export functions, and reference IDs embedded in form fields are common IDOR surfaces.

A minimal proof-of-concept looks like:

GET /api/orders/5512 HTTP/1.1
Authorization: Bearer <victim_token_not_needed>

# Attacker changes 5512 to 5513:
GET /api/orders/5513 HTTP/1.1
Authorization: Bearer <attacker_token>

HTTP/1.1 200 OK
{ "order_id": 5513, "customer": "victim@example.com", ... }

The server returns victim data because it looked up the order by ID without confirming that the authenticated user owns order 5513.

Business impact

The consequences of a successful IDOR exploit depend on the sensitivity of the exposed objects and the write permissions available:

  • Data breach: Personal Identifiable Information (PII), financial records, health data, or proprietary content belonging to other users can be exfiltrated in bulk through automated enumeration.
  • Regulatory and compliance exposure: Unauthorized access to personal data constitutes a reportable breach under GDPR (Article 33), HIPAA, PCI-DSS, and similar frameworks, potentially resulting in significant fines and mandatory notifications.
  • Account takeover: If profile or authentication objects are accessible via IDOR, attackers may change email addresses, passwords, or linked payment methods.
  • Data manipulation or destruction: Write-capable IDOR enables an attacker to alter or delete records, corrupt business-critical data, or disrupt service for other users.
  • Reputational damage: Public disclosure of an IDOR flaw that exposed customer data typically causes significant loss of customer trust.

IDOR vulnerabilities are among the most frequently rewarded findings in public bug bounty programs, often rated High or Critical depending on the data involved, which reflects their real-world exploitability.

How to fix it

  1. Enforce server-side authorization on every object access: After authenticating the request, verify that the authenticated principal (user, service account, or role) has explicit permission to read or modify the specific object identified in the request. This check must happen on the server — client-side filtering is insufficient.
  2. Use indirect reference maps: Instead of exposing raw database keys, maintain a per-session or per-user mapping between an opaque token and the actual object ID. Only the server resolves the mapping, so attackers cannot guess another user's valid token.
  3. Apply attribute-based or role-based access control (ABAC/RBAC): Model ownership and permission explicitly. For example, an ORM query should always scope results to the authenticated user: SELECT * FROM orders WHERE id = ? AND user_id = ? rather than SELECT * FROM orders WHERE id = ?.
  4. Avoid predictable identifiers where feasible: Using randomly generated UUIDs (v4) instead of sequential integers reduces the ease of enumeration, though this is a defense-in-depth measure, not a substitute for authorization.
  5. Implement and test access control centrally: Use a unified authorization middleware or library rather than ad-hoc per-endpoint checks. Inconsistency across endpoints is a primary cause of missed IDOR vulnerabilities.
  6. Log and alert on access anomalies: Rapid sequential access to object identifiers by a single account is a strong signal of IDOR enumeration. Implement rate limiting and anomaly detection on object-retrieval endpoints.
  7. Include IDOR scenarios in security testing: Automated scanners, manual penetration tests, and code reviews should explicitly test whether one authenticated session can access objects owned by a different session. Sensagraph automatically detects IDOR patterns across web application endpoints.

References

Frequently asked questions

No. IDOR affects any HTTP method that references an object by a user-controlled identifier, including POST, PUT, PATCH, and DELETE. Write-method IDOR can be more damaging because it allows modification or deletion of another user's data.

Broken Object Level Authorization (BOLA) is the term used in the OWASP API Security Top 10 (API1:2023) for the same fundamental weakness as IDOR. The term BOLA is preferred in API-centric discussions, while IDOR is the historically common term in web application security.

Create two separate authenticated user accounts and log all object identifiers encountered during normal use with account A. Then, using account B's session, attempt to access or modify those same identifiers. Any successful cross-account access indicates an IDOR vulnerability. Automated tools and purpose-built scanners can also detect common IDOR patterns at scale.

Yes. Obscuring an identifier makes enumeration harder but does not constitute an authorization check. If the server does not verify ownership when a UUID is supplied, an attacker who obtains that UUID through another means (e.g., a leaked URL, a log, or a shared link) can still access the resource without authorization.

Broken Access Control (OWASP A01:2021) is the broad category covering all failures to restrict what authenticated users can do. IDOR is a specific pattern within that category where the application exposes an internal object identifier and fails to verify the requesting user's authorization for that particular object before returning or modifying it.