Insecure direct object references (IDOR)

What is an insecure direct object reference?

Insecure direct object references (IDOR) are a type of access control vulnerability that occurs when an application exposes internal object identifiers – such as user IDs, account numbers, database keys, or file names – without verifying whether the requesting user is authorized to access the referenced object. This direct reference to internal resources can create a serious security risk if proper access control checks are missing.

Attackers can exploit this flaw by modifying identifiers in an HTTP request to access data that belongs to other users or privileged accounts. Because many applications rely on user-supplied input in request parameters, form fields, or JSON payloads, attackers may manipulate these values to gain direct access to sensitive objects.

Because modern web applications and APIs rely heavily on unique identifiers to retrieve database records, IDOR vulnerabilities remain one of the most common and impactful issues in web application security. When access control checks are missing or inconsistent, a single manipulated request can expose sensitive data across accounts, systems, or entire datasets and potentially lead to unauthorized access or even account takeover.

Basic IDOR example

Many applications use identifiers to retrieve data stored on the server. For example, an application might display transaction details using a request such as:

https://www.example.com/transaction?id=74656

Here, the identifier may correspond to database records that store transaction details. If the application only checks whether the user is authenticated and does not verify ownership of the referenced object, an attacker could modify the identifier:

https://www.example.com/transaction?id=74657

If transaction 74657 belongs to another user's account and the application still returns the data, the system contains an IDOR vulnerability. In this case, a malicious hacker can access sensitive information simply by manipulating identifiers in requests.

IDOR in the OWASP Top 10

The term insecure direct object reference was originally introduced in the OWASP Top 10 2007 as a separate vulnerability category. In later versions of the list, IDOR was merged into the broader category of broken access control.

Today, IDOR is considered a specific case of broken access control where applications expose object identifiers without properly verifying user permissions. These vulnerabilities remain common because modern applications rely heavily on identifiers and database keys to retrieve records, files, and other resources.

IDOR vs broken object-level authorization (BOLA)

In modern systems, the API equivalent of IDOR is commonly referred to as broken object-level authorization (BOLA). Both issues stem from the same root problem: the application fails to confirm that the requester is authorized to access a specific object.

The main difference lies in the context. IDOR as a general term is typically used with traditional web applications, while BOLA is a more specific type of IDOR found with APIs and service-based architectures.

For example, an API endpoint may return user data based on an identifier like 123. An API request to retrieve the user profile might look something like:

GET /api/users/123/profile

If the API does not verify that the requesting user is actually allowed to access profile 123 and the identifier is predictable, attackers may be able to retrieve other users’ data simply by modifying the identifier in the HTTP request or JSON payload.

Because APIs frequently expose identifiers as part of their design, BOLA is currently the most common vulnerability in the OWASP API Security Top 10.

How IDOR vulnerabilities work

At the core of every IDOR vulnerability is a missing authorization check.

A typical request flow may look like this:

1. A user authenticates with the application.
2. The user sends a request containing an object identifier.
3. The server retrieves the referenced object from the database or file system.
4. The server returns the object without verifying ownership.

Authentication alone is not sufficient to protect resources. Even if a user is properly logged in, the application must still confirm that the user is allowed to access the specific object being requested.

When this verification step is missing, attackers can manipulate identifiers to gain unauthorized access to resources.

Horizontal vs vertical privilege escalation

IDOR vulnerabilities often lead to privilege escalation. Two common variants are horizontal and vertical escalation.

Horizontal privilege escalation

Horizontal escalation occurs when a user accesses data belonging to another user with the same privilege level. For example, a user may access their account details using:

/account?id=1001

If the application returns another user’s data when the identifier is changed:

/account?id=1002

an attacker can retrieve information that should only be visible to another account holder.

This is the most common form of IDOR and can expose sensitive information from another user's account.

Vertical privilege escalation

Vertical escalation occurs when attackers gain access to resources belonging to users with higher privilege levels.

For example, an application might include an administrative endpoint:

/admin/user?id=1

If the application does not verify that the requester is an administrator, attackers may access administrative data or functionality by modifying identifiers.

Vertical escalation can expose sensitive administrative functions and may lead to full system compromise or account takeover.

Common IDOR attack patterns

IDOR vulnerabilities can appear in many different parts of an application. Some of the most common attack patterns include URL parameter tampering, form manipulation, API request modification, and file references.

URL parameter tampering

Many applications pass object identifiers in URL parameters, for example:

GET /invoice?id=455

Attackers may change the identifier to access other invoices:

GET /invoice?id=456

If the application does not verify that the invoice belongs to the requesting user, unauthorized data may be exposed.

Hidden form field manipulation

Instead of sending values in URL parameters that are visible in the browser, some applications include object identifiers inside hidden form fields, for example:

<input type="hidden" name="user_id" value="123">

Because hidden fields are part of the client-side request, attackers can easily modify them before submitting the form. If the server trusts the value without verifying authorization, attackers may access or modify other users’ data.

API request manipulation

Modern applications frequently rely on APIs to retrieve and update data. These APIs may expose object identifiers in requests.

Take an example API request to fetch order details for a specific user:

POST /api/orders
{
"user_id": 101,
"product_id": 33
}

If the API does not confirm that the currently authenticated user is allowed to act on behalf of user 101, attackers might be able to modify the identifier in the JSON request body to manipulate other users’ resources.

File and resource references

Applications sometimes allow users to retrieve files by referencing their names or paths, for example:

/download?file=report_2024.pdf

If the application does not validate file access permissions, attackers may retrieve files that should not be publicly accessible from the file system.

Note that while this scenario may resemble directory traversal (aka path traversal), the vulnerabilities are distinct. Directory traversal exploits path manipulation to access unintended locations in the file system, while IDOR exposes resources because the application fails to enforce authorization checks for referenced objects.

How attackers discover IDOR vulnerabilities

Attackers typically discover IDOR vulnerabilities by analyzing application requests and experimenting with object identifiers. A common approach involves the following steps:

1. Identify requests that reference objects by ID.
2. Intercept the HTTP request using tools such as Burp Suite or browser developer tools.
3. Modify identifiers in the request parameters, headers, or body.
4. Send the modified request to the server.
5. Observe whether unauthorized data is returned.

If the application returns data belonging to another user or resource, the endpoint likely contains an IDOR vulnerability.

Attackers often automate this process by generating large numbers of requests that iterate through sequential identifiers. This technique, known as enumeration, can expose entire datasets if proper access control checks are missing.

How to test for IDOR vulnerabilities

Testing for IDOR vulnerabilities requires verifying that the application enforces access control consistently for every request that references an object.

Manual IDOR testing

Manual testing is a common approach during penetration tests and cybersecurity assessments. A typical workflow includes:

1. Log in as a normal user.
2. Capture a request that retrieves a resource.
3. Modify the object identifier.
4. Resend the HTTP request.
5. Observe whether unauthorized data is returned.

If the application returns data belonging to another user, the endpoint likely contains an IDOR vulnerability.

Testing APIs for BOLA vulnerabilities

Testing APIs follows a similar approach. Given a request like:

GET /api/users/234/profile

a tester may modify the identifier:

GET /api/users/235/profile

If the API returns another user’s profile without verifying ownership, the endpoint has a broken object-level authorization vulnerability.

Testing APIs can be more complex because authorization decisions may depend on request sequences, tokens, or session state.

Detecting IDOR with automated security testing

Identifying IDOR vulnerabilities can be challenging because it requires evaluating authorization behavior rather than simply detecting malformed input or insecure code patterns.

Automated security testing tools can help identify potential authorization issues by probing applications with modified identifiers and analyzing responses. Modern dynamic testing solutions can detect patterns that indicate broken object-level authorization, especially in APIs.

Combining automated testing with manual verification provides the most comprehensive coverage, particularly for large applications with many endpoints.

How to prevent IDOR vulnerabilities

Preventing IDOR vulnerabilities requires implementing strong access control logic for every request that references sensitive objects.

Enforce object-level authorization

The most important defense against IDOR is verifying authorization for every request. The application should confirm that the requesting user is allowed to access the requested resource before returning any data.

Authorization checks must occur on the server side and cannot rely on client-side validation.

Avoid exposing direct identifiers when possible

Applications should avoid exposing internal identifiers directly to users whenever possible. Instead, they may use indirect references or tokens that map to internal database records.

This approach reduces the likelihood of enumeration attacks. However, indirect identifiers do not replace proper access control checks – they only add an additional layer of protection.

Use unpredictable object identifiers as an additional safeguard

Using non-sequential identifiers such as UUIDs, random identifiers, or other opaque tokens can make it harder for attackers to guess valid object references. Sequential or otherwise predictable numeric identifiers often allow simple enumeration attacks, where an attacker can iterate through identifiers to discover additional records.

Replacing predictable identifiers with UUIDs or randomly generated values reduces the likelihood that attackers can systematically discover objects. However, this approach only adds a layer of protection and does not replace proper access control checks. Even with unpredictable identifiers, the application must still verify on every request that the user is allowed to access the referenced object.

Implement consistent server-side validation

Client-side controls, hidden fields, and UI logic should never be trusted as the only protection mechanism. All access control decisions must be enforced on the server side, regardless of how the request is generated.

Apply least privilege principles

Applications should grant users only the permissions required for their tasks. Limiting privileges reduces the potential impact of IDOR vulnerabilities if they occur.

Role-based access control and policy-based authorization models can help enforce these restrictions.

Test access control continuously

Access control logic should be tested regularly throughout the development lifecycle. Security testing in development and CI/CD environments can help detect authorization flaws before applications reach production.

Automated scanning can also identify access control anomalies across large application environments and complex APIs.

Why IDOR still occurs in modern applications

Despite being well understood, IDOR vulnerabilities remain common in modern systems. Several factors contribute to their persistence:

• Complex application architectures – modern applications often consist of many services and APIs that may handle authorization differently.
• Rapid development cycles – development teams may prioritize functionality over security checks.
• Distributed systems – microservices may assume that authorization has already been performed by another service.
• Expanding API ecosystems – undocumented or shadow APIs may expose object identifiers without proper controls.

Because identifiers are fundamental to how applications retrieve data, failing to enforce authorization consistently across all endpoints can quickly introduce vulnerabilities.

How automated scanning helps with consistent IDOR detection

IDOR vulnerabilities persist because access control logic must be implemented consistently across every endpoint that references application objects. In complex environments with many APIs, microservices, and rapidly evolving codebases, verifying that authorization checks are correctly enforced can be difficult without automated security testing.

Dynamic application security testing (DAST) and API security scanning help identify access control weaknesses by probing applications with manipulated identifiers and analyzing how the system responds. Tools that validate exploitability can further reduce noise and help teams focus on issues that represent real risk.

To see how automated scanning can detect and validate IDOR and BOLA vulnerabilities across web applications and APIs, you can explore the capabilities of the Invicti Platform or request a demo to evaluate it in your own environment.