IDOR Vulnerability: Understanding Insecure Direct Object Reference, Exploitation Scenarios, and Prevention

Introduction

Insecure Direct Object Reference (IDOR) is a common web application security vulnerability that occurs when an application exposes references to internal objects, such as user accounts, invoices, documents, orders, or customer records, without properly verifying whether the requesting user is authorized to access or modify them.

IDOR vulnerabilities can allow attackers to access, modify, or delete information belonging to other users by manipulating identifiers in URLs, API requests, or application parameters.

Although the concept is relatively simple, the consequences can be severe, particularly in applications that handle sensitive customer information, financial records, healthcare data, or confidential business documents.

IDOR is closely associated with Broken Access Control, a major category of web application security risks identified by the OWASP Top 10. In API security, a closely related vulnerability is known as Broken Object Level Authorization (BOLA).

Understanding IDOR is essential for developers, penetration testers, application security engineers, and security researchers who assess the security of modern web applications and APIs.

What Is an IDOR Vulnerability?

Consider a web application that allows users to view their invoices through the following URL:

https://example.com/api/invoices/1001

The application retrieves the invoice associated with identifier 1001. If the application checks only whether the user is logged in, without verifying whether that invoice belongs to the user or is otherwise accessible to them, an attacker may be able to change the identifier.

For example:

https://example.com/api/invoices/1002

If the application returns another customer's invoice without performing the appropriate authorization checks, an IDOR vulnerability exists.

The underlying problem is not that the identifier is predictable. The problem is that the application fails to enforce authorization for the requested object.

Even UUIDs, randomly generated identifiers, and complex resource references do not eliminate the need for proper access control. An application must verify permissions regardless of whether an identifier is sequential, random, or difficult to guess.

How Does IDOR Work?

IDOR typically occurs when an application accepts a client-controlled identifier and uses it to retrieve, update, or delete a resource without validating the user's permissions.

A typical scenario begins when an authenticated user accesses a legitimate resource. The user or security tester identifies the resource reference in the request, changes that reference, and checks whether the application allows access to a resource outside the user's permissions.

Common locations where IDOR vulnerabilities may occur include:

• ›URL path parameters, such as /users/123/profile
• ›Query parameters, such as ?document_id=456
• ›JSON request bodies containing fields such as accountId or ownerId
• ›REST API endpoints that retrieve or modify individual records
• ›File download and document-sharing functionality
• ›Invoice, order, payment, and transaction management features
• ›Administrative interfaces and multi-tenant applications
• ›Mobile application API requests

The vulnerability can affect read operations as well as actions that create, update, share, or delete resources.

Common Types of IDOR Vulnerabilities

Unauthorized Data Access

An application allows one user to retrieve another user's private information by manipulating an object identifier.

Examples include accessing customer profiles, support tickets, personal documents, account details, or transaction histories.

Unauthorized Data Modification

An application allows a user to update a resource that belongs to another user.

For example, an inadequately protected API endpoint might accept a modified record identifier and update the corresponding account information without checking ownership or permissions.

Unauthorized Data Deletion

An application allows a user to delete another user's resource by changing an identifier in a deletion request.

This can lead to data loss, service disruption, and operational consequences.

IDOR in File Downloads

An application generates document download links using file or document identifiers. If authorization is not checked when a file is requested, an attacker may access confidential documents belonging to other users.

IDOR in Multi-Tenant Applications

In multi-tenant platforms, users from one organization may be able to access another organization's resources by manipulating tenant, project, account, or record identifiers.

This is particularly serious in Software-as-a-Service (SaaS) environments, where a single application may serve multiple customers.

IDOR in Mobile Applications

Mobile applications frequently communicate with backend APIs to retrieve profiles, transactions, documents, and other resources. If the backend relies on identifiers supplied by the mobile client without verifying authorization, an IDOR vulnerability may exist.

Hiding identifiers in the mobile interface or implementing client-side restrictions does not protect the underlying API.

IDOR Vulnerability in GET Requests

GET requests are commonly used to retrieve information from a server. IDOR vulnerabilities can occur when an application retrieves a resource based on an identifier without checking whether the authenticated user is permitted to access it.

Consider a hypothetical application that allows users to view profile information.

Legitimate request:

GET /api/users/101 HTTP/1.1
Host: example.com
Authorization: Bearer <access_token>

The application returns the profile associated with user ID 101.

During an authorized security assessment, a tester changes the identifier.

Modified request:

GET /api/users/102 HTTP/1.1
Host: example.com
Authorization: Bearer <access_token>

If the authenticated user has no permission to access user 102, but the server returns that user's private information, the endpoint may contain an IDOR vulnerability.

The expected behavior is to verify authorization before returning the protected resource. Depending on the application's design, the server may return 403 Forbidden, 404 Not Found, or another appropriate response that does not disclose protected information.

An identifier change alone does not prove a vulnerability. The tester must establish that the resource is outside the user's authorized access.

IDOR Vulnerability in POST Requests

IDOR vulnerabilities are not limited to GET requests. They can also occur in POST requests when an application accepts an object identifier in the request body and fails to verify whether the authenticated user is authorized to perform the requested action.

POST requests are commonly used to submit forms, create resources, initiate transactions, and execute application actions. Depending on the API design, a POST endpoint may also retrieve information or update an existing resource.

Example: Unauthorized Access to Another User's Data

Consider a hypothetical application that processes profile information through a POST endpoint.

Original request:

POST /api/profile/view HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer <access_token>

{
  "user_id": 101
}

The server processes the request and returns information associated with user ID 101.

An authorized security tester changes the identifier in the request body.

Modified request:

POST /api/profile/view HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer <access_token>

{
  "user_id": 102
}

If the authenticated user is not authorized to access user 102, but the application returns that user's private information, the endpoint contains an object-level authorization flaw.

The problem is not the POST method itself. The vulnerability exists because the server fails to enforce authorization for the requested object.

Example: IDOR in an Order Update Request

Consider an e-commerce application that allows customers to update delivery instructions for their orders.

Original request:

POST /api/orders/update-delivery HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer <access_token>

{
  "order_id": 5001,
  "delivery_note": "Leave the package at the reception."
}

Suppose order 5001 belongs to the authenticated customer and the request works as expected.

During authorized testing, the tester changes the order identifier to 5002.

Modified request:

POST /api/orders/update-delivery HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer <access_token>

{
  "order_id": 5002,
  "delivery_note": "Deliver to the alternate address."
}

If order 5002 belongs to another customer and the application updates it without checking permissions, the vulnerability allows unauthorized modification of another user's resource.

The application should reject the operation unless the authenticated user has permission to modify the specified order.

Example: IDOR Through a Document Identifier

Consider a document management platform that allows users to share documents.

Original request:

POST /api/documents/share HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer <access_token>

{
  "document_id": "doc-1001",
  "recipient_email": "colleague@example.com"
}

If the backend verifies only that the user is authenticated, an attacker may attempt to change document_id to another document reference.

If the application shares a document that the user is not authorized to manage, the endpoint may contain an IDOR vulnerability.

The server must verify that the requester has the required permission to share the specified document before performing the operation.

IDOR Vulnerability in PUT Requests

PUT requests are commonly used to replace an existing resource or update its representation. They can be vulnerable when the server processes a supplied resource identifier without verifying the requester's permissions.

Example request:

PUT /api/users/102 HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer <access_token>

{
  "name": "Updated User",
  "phone": "+1-555-0100"
}

Suppose the authenticated user is permitted to update only their own profile. If the application updates user 102 without checking whether the requester has permission to modify that account, an IDOR vulnerability may exist.

The application must enforce the appropriate authorization policy before applying the update.

IDOR Vulnerability in PATCH Requests

PATCH requests are typically used to make partial modifications to an existing resource.

Consider an application that allows users to update account information.

Example request:

PATCH /api/users/102 HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer <access_token>

{
  "phone": "+1-555-0100"
}

If the authenticated user is not authorized to modify user 102, the server must deny the request.

A common security mistake is to implement authorization checks for profile retrieval while forgetting to enforce equivalent checks in update endpoints.

Developers should also ensure that users cannot modify protected fields, such as roles, account ownership, or organization membership, simply by including those fields in a request body.

This latter issue may overlap with mass assignment or property-level authorization vulnerabilities, depending on the implementation.

IDOR Vulnerability in DELETE Requests

DELETE requests can expose a serious data-integrity risk when an application allows users to delete resources belonging to other users.

Example request:

DELETE /api/documents/7002 HTTP/1.1
Host: example.com
Authorization: Bearer <access_token>

If document 7002 belongs to another user and the server deletes it without checking authorization, the endpoint is vulnerable to IDOR.

The expected behavior is to deny deletion when the requester lacks the required permission.

Security testers should use disposable test records and controlled environments to avoid accidental data loss.

How to Identify IDOR Vulnerabilities

Security professionals should evaluate how applications enforce authorization across their APIs and user-facing functionality.

Review HTTP Requests

Use an authorized web security testing proxy to inspect requests and identify client-controlled resource identifiers.

Pay attention to endpoints that retrieve, update, delete, export, share, or download individual records.

Test with Different User Accounts

Where possible, use two test accounts with separate permissions and independently created test data.

Verify whether one account can access or modify resources belonging exclusively to the other account.

This approach helps establish whether the application enforces ownership and access-control boundaries.

Inspect API Authorization Logic

Review server-side handlers and data-access functions to determine whether they verify resource ownership, role permissions, tenant boundaries, and the required action.

Authentication alone is insufficient. The server must authorize each protected operation.

Test Different HTTP Methods

Check whether authorization is consistently enforced for relevant operations, including GET, POST, PUT, PATCH, and DELETE.

An endpoint may protect data retrieval correctly while leaving update or deletion operations vulnerable.

Check Indirect References

Do not limit testing to sequential numeric identifiers. Review UUIDs, nested resources, document references, hidden form fields, JSON properties, and identifiers passed between frontend components.

The key question is whether the server independently verifies access to the requested resource.

How to Test IDOR Using Burp Suite

Burp Suite can help security testers inspect and modify HTTP requests during an authorized assessment.

Capture a Legitimate Request

Log in using a test account and perform an action involving a resource, such as viewing a profile, updating an order, or downloading a document.

Send the Request to Repeater

Inspect the HTTP method, endpoint, authorization token, content type, and request body.

Identify Object References

Look for parameters such as user_id, account_id, order_id, document_id, and tenant_id.

Modify One Identifier at a Time

Use a second test account and resources you control. Change the object identifier to reference a resource that the first account should not be allowed to access.

Compare the Responses and Application State

Check whether the server returns protected information or performs an unauthorized modification. A successful HTTP status code alone does not prove that an IDOR exists.

For modification and deletion tests, verify the resulting state using controlled test data.

Document the Findings

Record the affected endpoint, HTTP method, parameter, required privileges, expected behavior, actual behavior, and evidence from the controlled test.

Do not access other customers' information or modify their resources during testing without explicit authorization.

Real-World Impact of IDOR

The impact of an IDOR vulnerability depends on the affected resource, the permissions required to exploit it, and the sensitivity of the exposed functionality.

Data exposure: Unauthorized access to personal information, confidential documents, customer records, or financial data.

Account compromise: Unauthorized changes to account details or security-related settings.

Financial impact: Exposure or manipulation of invoices, orders, payment records, or transaction information.

Cross-tenant data leakage: Access to another organization's information in a SaaS environment.

Data integrity violations: Unauthorized modification or deletion of business records.

Regulatory and reputational consequences: Potential privacy violations, incident response costs, regulatory scrutiny, and loss of customer trust.

In some circumstances, an IDOR vulnerability may be classified as a high-severity issue. However, severity should be determined by evaluating the actual impact, exploitability, affected data, and privileges required.

How to Prevent IDOR Vulnerabilities

Enforce Server-Side Authorization

Every request involving a protected resource must undergo an authorization check on the server.

Never rely exclusively on frontend controls, hidden fields, disabled buttons, or client-side validation to protect sensitive resources.

Validate Resource Ownership

Where resources belong to individual users, ensure the requested resource is accessible to the authenticated user.

For example, instead of retrieving a record solely by its identifier, the application's data-access logic can constrain the query by both the resource ID and the authenticated user's identity.

SELECT *
FROM invoices
WHERE id = :invoice_id
  AND owner_id = :authenticated_user_id;

The parameters must be safely bound, and the application must handle the case where no authorized record is found.

For shared resources, organizational resources, or delegated access, authorization should reflect the actual access-control policy rather than assuming ownership is the only valid permission model.

Apply Role-Based or Attribute-Based Access Control

Implement an authorization model that considers the user's role, resource ownership, organization, relationship to the resource, and required action.

For complex applications, centralized authorization policies can help ensure consistent enforcement across API endpoints.

Enforce Tenant Isolation

Multi-tenant applications should derive tenant context from trusted authentication and authorization mechanisms and enforce tenant boundaries in every relevant data-access operation.

Do not trust a client-supplied tenant identifier without independently validating that the user can access that tenant.

Use Indirect References as Defense in Depth

Opaque identifiers can reduce accidental exposure and make enumeration more difficult. However, they must not replace authorization checks.

A UUID is not an access-control mechanism.

Implement Automated Authorization Tests

Include authorization tests in the software development lifecycle.

Test whether users can access their own resources, whether unauthorized cross-user access is denied, and whether tenant boundaries remain intact during read, update, and delete operations.

Regression tests should cover sensitive endpoints and relevant permission combinations.

Monitor Suspicious Access Patterns

Monitor repeated requests involving many resource identifiers, unusual access to records across multiple accounts, and unexpected cross-tenant activity.

Logging should capture sufficient information for investigation while avoiding unnecessary storage of sensitive data, credentials, and authentication tokens.

IDOR vs. Broken Access Control vs. BOLA

IDOR is a specific vulnerability pattern in which an application fails to properly authorize access to a resource referenced by a client-controlled identifier.

Broken Access Control is the broader category covering failures to enforce intended permissions. It also includes privilege escalation, unauthorized administrative actions, and violations of access restrictions that do not necessarily involve object identifiers.

Broken Object Level Authorization (BOLA) is the API security term for failures to enforce authorization at the individual-object level. It frequently describes the same underlying class of problem encountered in IDOR testing.

These concepts are closely related, but they are not interchangeable in every context. IDOR describes a common implementation pattern, Broken Access Control describes the broader security weakness, and BOLA emphasizes object-level authorization in APIs.

IDOR Security Testing Checklist

Before releasing a web application or API, verify the following:

• ☐Each sensitive resource has an appropriate server-side authorization check.
• ☐Users cannot access another user's private resources without permission.
• ☐Unauthorized updates and deletions are prevented.
• ☐Tenant isolation is enforced consistently.
• ☐Authorization applies across relevant HTTP methods and API endpoints.
• ☐Hidden fields and client-supplied identifiers are not trusted as proof of authorization.
• ☐Automated tests cover authorized and unauthorized resource access.
• ☐Sensitive fields and administrative actions have appropriate permissions.
• ☐Security logs support investigation of suspicious access patterns.
• ☐Regression tests verify that authorization controls remain effective after application changes.

Conclusion

IDOR vulnerabilities often arise from a fundamental security oversight: an application verifies who the user is but fails to verify what that user is allowed to access.

These vulnerabilities can affect GET, POST, PUT, PATCH, and DELETE requests, making them relevant to nearly every application that exposes resource-based functionality through an API.

Preventing IDOR requires consistent server-side authorization, appropriate resource ownership checks, tenant isolation, and comprehensive testing across application functionality and APIs.

For development teams, the most effective approach is to incorporate object-level authorization into the application's architecture rather than treating it as a final security check.

For security professionals, the objective is to validate authorization boundaries systematically and demonstrate unauthorized access using controlled, explicitly authorized testing.

Secure every resource. Verify every permission. Never trust an identifier alone.

References

• ›OWASP Top 10: https://owasp.org/www-project-top-ten/
• ›OWASP API Security Top 10 — Broken Object Level Authorization: https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/
• ›PortSwigger Web Security Academy — Access Control: https://portswigger.net/web-security/access-control