IDOR Hunting Techniques Every Bug Bounty Hunter Should Know | by Samadhan Shimple

IDOR is one of the most interesting vulnerabilities to look for during a bug bounty hunt. It can appear in a simple profile page, a document download feature, an order history page, or an API that handles user data.

The tricky part is that everything may look normal when you browse the application. The vulnerability appears when you test whether the server properly checks who owns the resource being requested.

In this guide, we will explore how IDOR works, how to find potential vulnerabilities, which tools can help, and how to verify your findings without relying entirely on automated scanners.

What Is an IDOR Vulnerability?

IDOR stands for Insecure Direct Object Reference. It occurs when an application uses an identifier to access a resource but fails to verify whether the requesting user has permission to access that resource.

For example, imagine that an application displays your invoice at the following URL:

https://example.com/invoices/1001

You are logged in and can view your invoice. However, if changing 1001 to another invoice ID allows you to access someone else's private invoice, the application may have an IDOR vulnerability.

The main problem is not the predictable ID itself. The problem is the missing authorization check on the server.

This type of vulnerability is closely related to Broken Access Control and is commonly discussed alongside Broken Object Level Authorization (BOLA) in API security.

Why Do Bug Bounty Hunters Look for IDOR?

Applications often contain resources that belong to individual users, such as profiles, documents, orders, invoices, projects, and support tickets.

Every time an application handles these resources, it should verify that the current user has permission to perform the requested action.

If that check is missing or incorrectly implemented, one user might be able to access or modify another user's information.

Depending on the affected functionality, the impact could include unauthorized access to private data, modification of account information, or deletion of another user's resources.

However, not every identifier manipulation is a vulnerability. You must demonstrate that the application actually allows an unauthorized action.

Step 1: Understand the Application Before Testing

Before looking for IDOR, spend some time understanding how the application works.

Create an account in an authorized testing environment and explore its main features. Visit your profile, create a document, upload a file, view your orders, and interact with other available functionality.

Keep Burp Suite running while you browse. It will help you understand which requests are sent to the server and which parameters control the resources being accessed.

Pay particular attention to requests that retrieve, update, create, or delete user-owned objects.

Step 2: Find Parameters That Reference Objects

IDOR vulnerabilities can occur wherever an application uses an identifier to select a resource.

These identifiers are not always numeric. They can be usernames, UUIDs, document keys, filenames, or values embedded in JSON request bodies.

Here are some common examples:

URL path

GET /api/users/1042

Query parameter

GET /api/orders?user_id=1042

JSON request body

{"document_id":"doc_1042"}

GraphQL variables

{"query":"query { document(id: \"doc_1042\") { id } }"}

These examples are only possible places to investigate. Their presence does not automatically mean the application is vulnerable.

In Burp Suite, review the HTTP history and identify requests that contain resource identifiers. Record what each parameter appears to control and whether the resource belongs to your own account.

Also check less obvious locations, such as nested JSON fields and API endpoints used by multi-step workflows.

Step 3: Create Two Test Accounts

Using two separate accounts is one of the most useful ways to test for IDOR.

Create Account A and Account B with the same permissions. Use different browser profiles or separate sessions so you can clearly distinguish their requests.

For example, create a document using Account A and another document using Account B. Record the identifiers returned by the application and confirm that each account can access its own document.

Now you have a simple baseline for comparing how the application handles resources owned by different users.

Use accounts and resources you control, or test other users' resources only when the program's rules explicitly authorize that testing.

Step 4: Test Cross-Account Access

This is where the actual authorization testing begins.

Suppose Account A can access its own document through a request such as:

GET /api/documents/doc_A

Account B owns a different document:

GET /api/documents/doc_B

Using Account A's authenticated session, test whether the application allows access to Account B's document identifier in your authorized test environment.

Observe the response carefully. A successful HTTP status code alone does not prove a vulnerability. The response must show that Account A can access information or functionality that should be restricted to Account B.

If the application returns an authorization error or denies access, that is evidence that the access control may be working correctly for that request.

Repeat the test across relevant endpoints, because authorization can be implemented correctly in one part of an application and incorrectly in another.

Step 5: Test More Than Read Access

Many beginners focus only on whether they can view another resource. However, IDOR can also affect actions that modify or delete data.

I usually think about testing in three main categories.

1. Read IDOR

Can one account retrieve another account's private resource?

Examples include viewing an unauthorized invoice, reading a private document, or accessing another user's support ticket.

The impact depends on the sensitivity of the information exposed and how many resources are affected.

2. Write or Update IDOR

Can one account modify a resource owned by another account?

For example, an application might accept an object identifier when updating a document. If the server does not verify ownership or the user's permissions, an unauthorized user might be able to change that document.

Verify the result using test resources you control. Do not modify real users' information to demonstrate impact.

3. Delete IDOR

Can one account delete a resource that belongs to another account?

This can have a more serious impact when the resource is important or difficult to restore.

Use only disposable test resources and confirm that the action is actually performed. A successful-looking response without a real state change is not enough.

Remember that the same endpoint may enforce authorization differently for reading, updating, and deleting a resource.

Step 6: Use Burp Suite to Make Testing Easier

Burp Suite is one of the most useful tools for manual IDOR testing because it lets you inspect and replay HTTP requests.

Here are the features I find most useful.

HTTP history: Helps identify endpoints and parameters used throughout the application.

Repeater: Allows you to replay a request while changing a resource identifier and observing the response.

Proxy: Lets you inspect requests and responses as you interact with the application.

Intruder: Can help with controlled testing of identifiers in an explicitly authorized environment. Avoid indiscriminate enumeration, excessive request volumes, or accessing unrelated users' data.

You do not need to automate everything. A single carefully selected request can reveal an authorization problem that a scanner might overlook.

The important part is understanding the application's expected behavior and verifying the result.

Step 7: Try Useful Burp Suite Extensions

Extensions can make access-control testing more efficient, especially when you need to compare responses across different sessions.

Autorize

Autorize is designed to help test authorization by replaying requests with a different user's credentials and comparing the results.

It can identify suspicious responses, but a difference or similarity between responses does not automatically confirm an IDOR. You still need to verify whether unauthorized access actually occurred.

Authz

Authorization-testing extensions can help assess whether users with different permissions can access protected functionality.

Choose an actively maintained extension that supports your Burp Suite version, and review its configuration before running it.

OWASP ZAP and Caido

If you do not use Burp Suite, OWASP ZAP and Caido can also help inspect and manipulate HTTP traffic.

The specific workflow depends on the tool and the application's authentication model.

Important: Extensions automate parts of the testing process, not the reasoning. They may miss business logic flaws or generate false positives.

Step 8: Can Automated Scanners Find IDOR?

Automated tools can identify suspicious parameters, replay requests, and compare responses. Some tools can also use multiple authenticated sessions to test access control.

However, IDOR is often difficult to detect automatically because the scanner needs to understand which user owns a resource and what permissions should apply.

A response containing another user's data may be a genuine finding, while a response with a different status code could simply reflect normal application behavior.

For reliable results, combine automated testing with manual verification.

Start by understanding the feature, identify a resource you control, compare behavior across two accounts, and confirm whether an unauthorized action succeeds.

That approach is generally more useful than blindly scanning every identifier you find.

Step 9: Look Beyond Simple Numeric IDs

Not every IDOR uses an identifier such as 1001 or 1002.

Applications may use UUIDs, opaque strings, document references, nested object IDs, or identifiers returned by earlier API requests.

A UUID may be difficult to guess, but unpredictability is not a replacement for authorization. If a user can obtain another resource's identifier, the server must still check whether they are allowed to access it.

You should also examine multi-step workflows.

For example, an application may correctly check access when a document is first opened but fail to verify permissions when the same document is exported, shared, or updated through another endpoint.

Test each relevant operation separately and pay attention to how ownership and permissions are handled throughout the workflow.

Step 10: Understand the Impact Before Reporting

Finding suspicious behavior is only the beginning. A useful bug bounty report must explain why the behavior matters.

Consider a hypothetical application where Account A can access Account B's private invoice by changing the invoice identifier.

The possible impact is unauthorized disclosure of invoice information. The severity depends on the sensitivity of the exposed data, the scope of access, and the practical consequences.

An issue that exposes harmless public information may have little or no security impact. An issue that exposes sensitive financial information across many accounts may be substantially more serious.

Do not assign severity based only on the vulnerability name. Base it on the demonstrated impact and the program's severity guidelines.

Common Mistakes to Avoid

A few mistakes can waste time or lead to invalid reports.

• Testing with only one account: Without a second account, it is often difficult to establish resource ownership and demonstrate a cross-account authorization failure.
• Assuming every ID is vulnerable: An identifier in a URL is not proof of missing authorization.
• Trusting status codes alone: Verify the response content and, where relevant, whether the resource actually changed.
• Ignoring other operations: Read access may be protected even when an update or export endpoint is not.
• Relying entirely on scanners: Automated results require manual validation.
• Overlooking program rules: Stay within the authorized scope and avoid unnecessary access to private data.

Good testing is not about making as many requests as possible. It is about gathering enough evidence to demonstrate a real security weakness.

Final Thoughts

IDOR testing is not just about changing numbers in URLs. It is about understanding how an application identifies resources and whether the server correctly enforces authorization for every operation.

Burp Suite, authorization-testing extensions, and automated scanners can speed up the process. However, the most important skills are identifying meaningful test cases, comparing behavior across accounts, and proving that an unauthorized action is possible.

Start with a small number of carefully selected endpoints, use accounts you control, and verify every finding before reporting it.

The key lesson is simple: knowing a resource's identifier should never be enough to gain access to it. Authorization must be enforced by the server on every relevant request.

AI assistance:_ I used an AI-powered grammar and spelling checker to review this article. The ideas, research, technical analysis, and final content are my own._

Have questions or want to share your own workflow? Drop a comment below or connect with me on :

🔗Linkdin: https://www.linkedin.com/company/sam-shield/

🔗Youtube: https://www.youtube.com/@sam_shield-w7l

🔗Medium: https://medium.com/@samadhanshimple