What Is an IDOR Vulnerability?

An IDOR (Insecure Direct Object Reference) vulnerability occurs when a web application allows a user to access an object or resource by changing an identifier, without properly checking whether they are authorised to access it.

IDOR vulnerabilities are a common form of broken access control and can allow attackers to access information belonging to other users, customers or organisations.

How Does an IDOR Vulnerability Work?

Web applications frequently use identifiers to retrieve resources. These might include:

• User IDs
• Customer numbers
• Invoice numbers
• Document IDs
• Order numbers
• File names
• Database record IDs

For example, a web application might provide a user with a URL such as:

https://example.com/invoices/12345

If the application correctly verifies that the logged-in user is authorised to view invoice 12345, there is no problem.

However, if a user can simply change the number:

https://example.com/invoices/12346

and retrieve another customer's invoice, the application may contain an IDOR vulnerability.

The problem is not that the identifier is visible. The problem is that the application has failed to enforce authorisation on the underlying resource.

A Simple Example

Imagine an online customer portal where users can view their account details.

A legitimate request might look something like:

GET /api/users/1001

The application returns the details belonging to user 1001.

An attacker changes the request to:

GET /api/users/1002

If the application returns the details of user 1002 without checking whether the attacker is authorised to access them, the application has an access control weakness.

Depending on what the application exposes, this could reveal names, addresses, contact information, documents, financial information or other sensitive data.

IDOR Isn't Limited to URLs

Although IDOR vulnerabilities are often demonstrated by changing a number in a URL, they can occur in many different parts of an application.

For example, an application might accept an object identifier in:

• URL parameters
• POST parameters
• JSON requests
• API requests
• Cookies
• HTTP headers
• File download requests

An attacker may therefore manipulate a request rather than simply changing a URL in their browser.

Modern web applications and APIs can be particularly susceptible because they often expose large numbers of resources through predictable API endpoints.

Why Are IDOR Vulnerabilities Dangerous?

The impact depends on what the vulnerable application allows a user to access.

A relatively simple IDOR might allow one user to view another user's profile.

A more serious vulnerability could allow an attacker to:

• Download another customer's documents
• View private messages
• Access invoices or financial records
• Modify another user's information
• Access administrative functionality
• Retrieve files belonging to another organisation
• Access sensitive API data
• Perform actions on behalf of another user

In a multi-tenant application, the consequences can be particularly serious.

For example, if a SaaS application does not correctly enforce tenant boundaries, a customer of the service could potentially access information belonging to another customer.

IDOR and Broken Access Control

IDOR is closely related to broken access control.

Broken access control is the broader security problem where an application does not correctly enforce what users are allowed to access or do.

IDOR is one way that this weakness can manifest.

For example:

User A should only be able to access their own invoice records.

If User A can change an invoice ID and retrieve User B's invoice, the application has failed to enforce that access control requirement.

This is why IDOR vulnerabilities are often categorised under Broken Access Control, including within the OWASP Top 10.

How Do Penetration Testers Find IDOR Vulnerabilities?

Identifying IDOR vulnerabilities is one reason manual testing remains important when assessing web applications.

A penetration tester will typically create or use multiple accounts and examine how the application handles access to resources belonging to different users.

For example, the tester might:

1. Log in as User A.
2. Identify a request that retrieves one of User A's resources.
3. Modify the resource identifier.
4. Determine whether the application returns User B's resource.
5. Test whether the resource can also be modified or deleted.
6. Assess whether the issue crosses organisational or tenant boundaries.

Testing is not limited to simply changing sequential numbers.

A tester may also examine UUIDs, encoded identifiers and API requests to determine whether the application's authorisation controls are actually being enforced.

Importantly, using unpredictable identifiers is not a substitute for access control.

An application should not rely on an identifier being difficult to guess. Even if an application uses UUIDs rather than sequential numbers, it still needs to verify that the requesting user is authorised to access the requested resource.

How Can Organisations Prevent IDOR Vulnerabilities?

The most important protection is server-side authorisation checking.

Every request for a protected resource should be checked to determine whether the authenticated user has permission to access that specific resource.

For example, an application should effectively ask:

"Does this authenticated user have permission to access this particular invoice?"

rather than simply:

"Is this user logged in?"

Developers should also:

• Enforce authorisation on the server side
• Apply access controls to every protected object
• Avoid relying on client-side security controls
• Test access controls using multiple user accounts
• Pay particular attention to API endpoints
• Enforce tenant isolation in multi-tenant applications
• Apply least-privilege principles
• Log and monitor suspicious access attempts

Changing database IDs to UUIDs can make enumeration more difficult, but it should be considered an additional layer of defence rather than a solution to the underlying vulnerability.

Can Vulnerability Scanners Find IDOR?

Automated vulnerability scanners can identify some classes of web application vulnerabilities, but IDOR can be difficult to detect reliably without understanding the application's intended access model.

A scanner may be able to identify interesting parameters or endpoints, but determining whether User A should be allowed to access User B's particular resource generally requires knowledge of the application's users, roles and permissions.

This is one reason manual testing is an important part of a comprehensive web application penetration test.

An experienced tester can test the application from the perspective of different users and deliberately attempt to cross those security boundaries.

Why Web Application Penetration Testing Matters

IDOR vulnerabilities can sometimes be difficult to identify through traditional vulnerability scanning alone because the issue is not necessarily a missing security patch or an identifiable software vulnerability.

The application may be completely up to date and still have a serious access control flaw.

A web application penetration test combines automated testing with manual assessment to determine whether users can access functionality and data they should not be able to reach.

This can be particularly important for applications handling sensitive customer information, financial data, healthcare information, business documents or data belonging to multiple organisations.

Conclusion

An IDOR vulnerability occurs when an application exposes a resource through a reference or identifier without properly checking whether the user is authorised to access it.

The consequences can range from unauthorised access to individual records through to significant data exposure across customers or tenants.

Strong server-side authorisation controls are the primary defence. However, organisations should also test those controls regularly, particularly where applications expose sensitive information through web interfaces or APIs.

IDOR testing is therefore an important component of a thorough web application penetration test, helping organisations identify access control weaknesses that automated scanning may not reliably detect.