Insecure Direct Object Reference (IDOR) is a common web application security vulnerability that occurs when an application exposes a reference to an internal object, such as a user account, invoice, document, or database record, without properly checking whether the requesting user is authorized to access it.
In March 2026, GitHub Security Lab disclosed an IDOR in Zammad v6.5.2, tracked as GHSL-2026-049. The flaw affected the ticket_related API endpoint and allowed an authenticated agent to access sensitive tickets belonging to groups they were not authorized to access.
For security teams, IDOR testing is therefore less about guessing identifiers and more about verifying that every request is subject to proper server-side authorization controls.
IDOR stands for Insecure Direct Object Reference.
It occurs when an application uses user-controllable input to directly reference an internal resource but fails to verify that the user has permission to access that resource.
For example, consider an API request:
GET /api/invoices/1001
A logged-in user may legitimately have access to invoice ‘1001’. If the user changes the request to:
GET /api/invoices/1002
and receives another customer's invoice, the application has an authorization flaw.
The identifier itself is not the vulnerability. Using sequential IDs, UUIDs, filenames, or other object references can all be legitimate design choices. The problem occurs when the server trusts the supplied identifier without enforcing authorization.
BOLA (Broken Object Level Authorization) is the term used by OWASP API Security for what is commonly known as IDOR (Insecure Direct Object Reference). Both describe the same core authorization vulnerability.
The difference is mainly terminology:
In practice, horizontal and cross-tenant IDORs are especially important in APIs, because object IDs frequently appear in paths, query parameters, and request bodies.
IDOR can appear wherever an application references objects through user-controllable values.
Common examples include:
The impact depends on what the exposed object contains and what actions the attacker can perform.
A ‘read-only IDOR’ could expose personal information, financial records, or confidential documents. A write or delete operation could allow an attacker to modify or destroy another user's data.
IDOR vulnerabilities can expose sensitive information or enable unauthorized actions without requiring an attacker to compromise another user's credentials.
Potential impact includes:
The risk becomes particularly significant in multi-tenant applications. If authorization is not correctly enforced between tenants, one customer could potentially access another customer's resources.
Testing for IDOR should focus on authorization boundaries.
A structured test can be performed as follows.
Start by mapping endpoints that accept identifiers or references to application objects. Look for parameters such as:
user_id
account_id
document_id
order_id
invoice_id
project_id
file_id
Also inspect URL paths, query parameters, request bodies, and API payloads.
For example:
GET /api/orders/123
GET /api/documents/456
POST /api/users/789/settings
The goal is to identify where a user's request determines which object the server accesses.
Use two accounts with different authorization contexts.
For example:
User A: owns Object A
User B: owns Object B
This allows you to test whether User A can access or modify resources belonging to User B. For security testing, these should be authorized test accounts and test data.
Log in as User A and access one of their resources.
For example:
GET /api/orders/1001
Record the request and response. Then identify which part of the request references the object.
Change the object identifier to a resource belonging to User B:
GET /api/orders/1002
Send the request while remaining authenticated as User A. The expected secure behavior is that the application rejects the request, for example, with an appropriate authorization response.
If User A receives User B's order, the endpoint may have an IDOR vulnerability.
IDOR is not limited to GET requests. Each operation should independently enforce authorization. Test whether unauthorized users can:
For example:
GET /api/orders/1002
PUT /api/orders/1002
DELETE /api/orders/1002
A comprehensive IDOR assessment should test more than just two ordinary users. Where applicable, test boundaries such as:
This helps identify broken object-level authorization across different roles and organizational boundaries.
Use this checklist when assessing an application:
☐ Identify endpoints containing object references.
☐ Create multiple authorized test accounts.
☐ Map resources owned by each account.
☐ Capture legitimate requests.
☐ Change object identifiers.
☐ Test unauthorized read access.
☐ Test unauthorized modification.
☐ Test unauthorized deletion.
☐ Test file and document access.
☐ Test user, role, and tenant boundaries.
☐ Verify server-side authorization.
☐ Document evidence for every confirmed finding.
Broken Object Level Authorization (BOLA), commonly known as IDOR (Insecure Direct Object Reference), doesn't require sophisticated payloads. It requires testing whether a user can access an object that belongs to someone else.
You provide two IDs for each parameter: one the user is authorized to access and one they should not be able to reach.
Siemba automatically generates and executes the test cases, then returns reproducible curl commands and evidence for confirmed findings.
For scenarios that require deeper context, Siemba's certified testers go beyond automation to validate chained workflows, privilege boundaries, and function-level authorization, areas where understanding the application's roles, relationships, and business logic matters.
Unlike traditional scanners that focus primarily on endpoint discovery, Siemba analyzes API structures, relationships, authorization models, and business logic. It effectively identifies vulnerabilities that are often missed during conventional assessments through API security testing.
Identify, test, and remediate security weaknesses across modern apps, including AI agents, LLMs, MCPs, and supporting infrastructure → Book a Demo.
Yes. IDOR is not limited to reading data. If authorization checks are missing, attackers may also modify, delete, download, or perform actions on unauthorized resources.
IDOR can occur wherever APIs use object references, including URL paths, query parameters, request bodies, headers, and resource identifiers.
APIs should enforce authorization on every object request and verify that the authenticated user or service is permitted to access the specific resource, not simply rely on whether the object ID is valid.
Yes. Automated tools can test object references at scale, while complex workflows, privilege boundaries, and business logic may require human validation. To know how → Book a Demo