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.

Key Takeaways

• IDOR is an authorization flaw that allows unauthorized access to objects.
• Common types: Horizontal, vertical, cross-tenant, unauthenticated, and read/write IDOR.
• Test object-level authorization across users, roles, and tenants.
• Test all operations: Read, modify, delete, download, and other actions.
• Automate ID testing across API paths, query parameters, and request bodies.
• Use human validation for complex workflows, privilege boundaries, and business logic.
• See how Siemba combines automated IDOR testing with expert validation and evidence.

What is IDOR?

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.

IDOR vs BOLA: What’s the Difference?

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:

• IDOR: Commonly used for web applications
• BOLA: OWASP’s API security terminology

Types of IDOR

• Horizontal IDOR: A user accesses another user's resource at the same privilege level.
  Example: User A changes user_id=101 to user_id=102 and accesses User B's profile.
  
  
• Vertical IDOR: A lower-privileged user accesses a resource belonging to a higher-privileged role.
  Example: A regular user changes an admin_id or resource ID and accesses an administrator-only record.
  
  
• Cross-Tenant IDOR: A user accesses an object belonging to another organization or tenant.
  Example: A customer changes an invoice_id and retrieves an invoice belonging to another company.
  
  
• Unauthenticated IDOR: An object can be accessed by manipulating its identifier without authentication.
  
  Example: Changing /documents/1001 to /documents/1002 exposes another user's document without requiring a login.
  
  
• Read vs. Write IDOR: IDOR can involve either unauthorized access or unauthorized actions. A ‘read IDOR’ might expose another user's data, while a ‘write IDOR’ could let an attacker modify or delete it.

In practice, horizontal and cross-tenant IDORs are especially important in APIs, because object IDs frequently appear in paths, query parameters, and request bodies.

Common Examples of IDOR

IDOR can appear wherever an application references objects through user-controllable values.

Common examples include:

• User accounts: /users/123
• Orders: /orders/4567
• Invoices: /invoices/8899
• Documents: /documents/234
• Support tickets: /tickets/782
• Images or files: /download?file=customer-report.pdf
• API resources: /api/projects/100/tasks/25
• Database-backed records: /api/records/12345

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.

Why IDOR is a Serious Security Risk

IDOR vulnerabilities can expose sensitive information or enable unauthorized actions without requiring an attacker to compromise another user's credentials.

Potential impact includes:

• Exposure of personally identifiable information
• Unauthorized access to financial records
• Disclosure of confidential documents
• Modification of another user's data
• Unauthorized deletion of resources
• Access to administrative or internal functionality
• Cross-tenant data exposure in SaaS applications

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.

How to Security Test for IDOR

Testing for IDOR should focus on authorization boundaries.

A structured test can be performed as follows.

1. Identify Object References

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.

2. Create Two Test Accounts

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.

3. Capture a Legitimate Request

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.

4. Replace the Object Reference

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.

5. Test More Than Read Access

IDOR is not limited to GET requests. Each operation should independently enforce authorization. Test whether unauthorized users can:

• Read an object
• Modify an object
• Delete an object
• Download a file
• Change account information
• Trigger an action against another user's resource

For example:

GET /api/orders/1002

PUT /api/orders/1002

DELETE /api/orders/1002

6. Test Different Authorization Boundaries

A comprehensive IDOR assessment should test more than just two ordinary users. Where applicable, test boundaries such as:

• User-to-user
• User-to-admin
• Employee-to-employee
• Tenant-to-tenant
• Department-to-department
• Resource owner-to-non-owner

This helps identify broken object-level authorization across different roles and organizational boundaries.

IDOR Security Testing Checklist

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.

How Siemba Tests IDOR

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.

Frequently Asked Questions

Can IDOR vulnerabilities allow users to modify or delete data?

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.

Where can IDOR vulnerabilities occur in an API?

IDOR can occur wherever APIs use object references, including URL paths, query parameters, request bodies, headers, and resource identifiers.

How can developers prevent IDOR vulnerabilities?

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.

Can IDOR testing be automated?

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