Insecure Direct Object Reference (IDOR), now commonly discussed by OWASP as Broken Object Level Authorization (BOLA), is one of the most important authorization issues to test in APIs.

The vulnerability occurs when an application accepts a user-controlled object identifier but fails to verify whether that user is authorized to access the referenced resource.

Recently, phpMyFAQ’s Admin API had an IDOR vulnerability that caused an authenticated administrator to change any user’s password by modifying the ‘userId’ in the API request. A low-privilege admin can exploit this to take over a SuperAdmin (userId=1) account and gain full administrative control.

Automated IDOR testing can catch many of these cases quickly and repeatedly. But changing an ID is only the beginning. Determining whether access is actually unauthorized and understanding complex authorization relationships can require additional context.

Human validation provides that context and depth to IDOR testing.

Key Takeaways

• IDOR/BOLA occurs when an API fails to verify whether a user is authorized to access a referenced object.
• Automation efficiently detects object-ID manipulation across paths, parameters, request bodies, and different HTTP methods.
• Automated testing is valuable for scale and regression testing, helping repeatedly check authorization controls as APIs change.
• Successful access does not automatically mean an IDOR exists. Business relationships, shared resources, roles, and tenant structures determine whether access is actually unauthorized.
• Human validation is essential for complex scenarios, including business logic, chained workflows, privilege escalation, and multi-step authorization decisions.
• The strongest approach combines automation with human expertise: automate repetitive, high-volume checks and use human testers to validate context, impact, and complex attack paths.

What Automated IDOR Testing Can Catch

Automated testing is particularly effective when the application has predictable object references and clearly defined authorization contexts.

1. Object Identifier Manipulation

The most straightforward IDOR test is changing an object identifier and comparing the response.

For example:

GET /api/orders/1001

GET /api/orders/1002

An automated test can determine whether changing the ID produces a response that appears to expose another resource. This approach can be applied to identifiers in:

• URL paths
• Query parameters
• Request bodies
• REST API parameters
• Object references within API payloads

Common examples include:

user_id

account_id

order_id

document_id

invoice_id

project_id

file_id

Automation makes it possible to test large numbers of these parameters consistently.

2. Horizontal Authorization Testing

Automated IDOR testing can compare resources belonging to users with the same privilege level.

For example:

• User A owns Object A
• User B owns Object B
• User A attempts to access Object B

The testing system can supply both object IDs and determine whether the second request is improperly authorized.

This is particularly useful for applications with large numbers of users and resources where manually testing every object would be impractical.

3. Testing Multiple HTTP Methods

IDOR isn't limited to data exposure through GET requests.

Automated testing can also examine whether object-level authorization is enforced for operations such as:

GET /api/orders/1002

PUT /api/orders/1002

DELETE /api/orders/1002

A resource might be correctly protected against unauthorized reading but still be vulnerable to unauthorized modification or deletion. Testing different methods helps establish whether authorization is consistently enforced across operations.

4. Repeatable Regression Testing

One of the biggest advantages of automation is repeatability. An IDOR vulnerability that was fixed today could reappear after a code change, API update, or authorization-policy modification.

Automated tests can be run repeatedly against new builds or releases to check whether previously identified authorization controls continue to work.

This makes automated IDOR testing useful as part of an ongoing API security program rather than only during periodic penetration tests.

5. Evidence and Reproduction

Useful automated testing should do more than report that an endpoint "failed."

A meaningful result should show what was tested, which object references were used, what response was received, and why the behavior indicates a potential authorization issue.

Reproducible evidence such as the request or a curl command also makes it easier for security and engineering teams to investigate and remediate the finding.

Read more about Penetration Testing Report: What It Includes and How to Read One.

Where Automated IDOR Testing Has Limits

Automation can determine that a request succeeded. It cannot always determine whether that success violates the application's intended authorization model.

That distinction becomes important as applications become more complex.

1. Understanding Business Relationships

Consider an API that returns:

GET /api/accounts/1042

An automated system may determine that the request returns data. But should the authenticated user be allowed to access account 1042?

That depends on the application's business rules.

Perhaps the account belongs to the user's organization. Perhaps the user is an auditor with read-only access. Perhaps the account is deliberately shared between multiple users.

Without that context, a scanner may identify unusual behavior without being able to establish whether it represents a vulnerability.

2. Complex Authorization Models

Modern applications can have relationships involving users, organizations, tenants, departments, roles, resource owners, administrators, and service accounts.

An IDOR test may therefore need to evaluate more than User A versus User B.

For example: User → Department → Organization → Resource

The correct authorization decision may depend on several relationships simultaneously. Human testers can reason through these relationships and identify authorization boundaries that aren't obvious from individual API requests.

3. Chained Workflows

Some authorization vulnerabilities only appear after a sequence of actions.

Consider this example to create an account:

1. Add user
2. Assign role
3. Create resource
4. Share resource
5. Modify resource

Testing each endpoint independently may not reveal the vulnerability; the whole chain of events determines where the vulnerability may reside.

A tester may need to understand how permissions change throughout the workflow and whether an action in one step creates unauthorized access in another. This is where business-logic testing becomes particularly important.

4. Privilege Escalation

IDOR can also overlap with vertical authorization problems.

For example, a regular user might discover an object associated with an administrative workflow. Simply changing the object ID may not be enough to exploit the issue; the tester may need to understand how the application determines roles and permissions.

Human validation can help determine whether an apparent access-control weakness actually crosses a meaningful privilege boundary.

5. False Positives and Inconclusive Results

An automated system may identify a difference in responses, but that doesn't automatically confirm a vulnerability.

The application might return a generic object, a deliberately shared resource, a cached response, a permission-independent record, or a non-sensitive object.

Conversely, an automated test may not have enough information to prove whether an authorization decision is correct. This is why IDOR testing should distinguish between potential access, validated unauthorized access, and cases requiring human review.

Where Human Validation Still Matters

Human penetration testers add context that automated testing may not have.

They can examine:

Business Logic

An automated test may find a refund endpoint:

POST /api/orders/123/refund

A human tester can determine whether the same order can be refunded again after the first refund, exposing a business-logic flaw.

User and Tenant Relationships

An automated test may identify that a user can access:

GET /api/invoices/456

A human tester can verify whether invoice 456 belongs to another customer or tenant and whether it exposes cross-tenant data.

Privilege Boundaries

A regular user may be able to call:

PUT /api/users/789/role

A human tester can determine whether changing the role parameter from user to admin results in privilege escalation.

Complex Workflows

Consider a password-reset flow:

POST /api/password-reset/request

POST /api/password-reset/verify

POST /api/password-reset/confirm

A human tester can evaluate whether authorization is consistently enforced across all three steps and whether one step can be bypassed.

Chained Attack Paths

A tester might discover:

GET /api/users/123

exposes an internal user ID, which can then be used with:

PUT /api/users/123/email

to modify another user's email. The individual findings may appear limited, but together they could create a more significant attack path.

Function-level Authorization

A standard user might discover an administrative endpoint:

DELETE /api/admin/users/123

A human tester can verify whether the endpoint actually enforces an administrator-only permission instead of relying on the UI to hide it.

Resource Ownership

An API may expose:

DELETE /api/documents/456

A human tester can change the document ID and determine whether User A can delete a document owned by User B.

Multi-step Authorization Decisions

An application may allow users to switch organizations with:

POST /api/organizations/456/switch

followed by:

GET /api/reports

A human tester can verify whether the second request correctly uses the newly selected tenant's authorization context or accidentally exposes another organization's reports.

The goal isn't to choose between automation and human testing. It is to use each where it provides the most value.

Read: API Security Testing: How to Cover REST, GraphQL, and SOAP Automatically.

Building an Effective IDOR Testing Strategy

A practical IDOR testing program should combine several layers:

1. Start with API Discovery:
   Identify endpoints and parameters that reference objects. Use API collections, observed traffic, and other available API inventory sources.
   
   
2. Test Multiple Identities:
   Use authorized test accounts with different ownership, roles, and tenant relationships.
   
   
3. Automate Repetitive Checks:
   Automate identifier manipulation across large API inventories and repeat the tests as APIs change.
   
   
4. Validate Meaningful Findings:
   Investigate whether successful access actually crosses an authorization boundary.
   
   
5. Test Beyond GET Requests:
   Check whether unauthorized users can modify, delete, download, or perform actions against another user's resources.
   
   
6. Retest after Remediation:
   A finding isn't fully closed simply because a developer changes the code. Retest the original scenario and verify that the authorization control now prevents unauthorized access.

How Siemba Approaches Automated and Manual IDOR Testing

Siemba’s expert-led pentesting combines automated testing with human validation for authorization scenarios that require deeper context.

For IDOR/BOLA testing, the setup can be straightforward: provide two IDs for a parameter, one representing a resource the user is authorized to access and another they should not be able to reach.

Siemba generates and executes the relevant test cases across API parameters, including identifiers in paths, query parameters, and request bodies. Confirmed results can include reproducible curl commands and evidence that helps security teams verify the behavior.

The automated layer provides the breadth needed to test API endpoints consistently.

For scenarios that require additional reasoning, Siemba's certified expert testers can validate what automation alone may not be able to establish, including chained workflows, privilege boundaries, function-level authorization, and complex business logic.

Unlike traditional scanners that focus primarily on endpoint discovery, Siemba’s autonomous platform 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

Why can automated IDOR scanners produce false positives?

A successful response does not necessarily indicate unauthorized access. Resources may be intentionally shared, non-sensitive, or accessible through legitimate business relationships.

Should IDOR testing be performed only during penetration tests?

No. Automated IDOR tests can be incorporated into CI/CD and regression testing so authorization controls are continuously checked as APIs change.

Can an IDOR vulnerability exist without exposing sensitive data?

Yes. IDOR can allow unauthorized users to modify, delete, or perform actions on resources even when no sensitive information is directly exposed.

Can IDOR vulnerabilities affect POST, PUT, and DELETE requests?

Yes. IDOR is not limited to GET requests. Authorization should be enforced for every operation that accesses or modifies an object.

How do you confirm whether an IDOR finding is a real vulnerability?

Test the request using identities with different ownership, roles, or tenant relationships and verify whether the response crosses an intended authorization boundary.

Can IDOR lead to account takeover?

Yes. If an exposed object controls sensitive account functions such as passwords, email addresses, or roles, an IDOR can potentially lead to account takeover or privilege escalation.