How I Use AI to Find Potential IDOR Vulnerabilities: A Practical 6-Step Guide | by Samadhan Shimple

Sometimes, the interesting part is hidden inside a JSON request, an API endpoint, or a feature that allows users to view or update their own information. The challenge is knowing which requests are worth testing and how to verify whether the application is actually missing an access control check.

While testing web applications, one thing becomes clear: AI can help you identify potential IDOR parameters faster, but manual testing is still needed to confirm the vulnerability.

In this article, I will explain a practical six-step workflow for using AI and Burp Suite to identify and test potential IDOR vulnerabilities in applications where you have permission to perform security testing.

What Is an IDOR Vulnerability?

IDOR stands for Insecure Direct Object Reference. It is a type of broken access control vulnerability that occurs when an application allows a user to access or modify an object without properly checking whether they have permission to do so.

For example, imagine an application that allows users to view their orders through an API endpoint:

GET /api/orders/1001

The application should verify that the logged-in user owns order 1001 before returning its details.

If changing the identifier allows that user to access another person's private order, the application may have an IDOR vulnerability.

The problem is not simply that the identifier can be changed. The real issue is that the server fails to enforce the correct access permissions.

Why Use AI for IDOR Hunting?

During a security assessment, an application may generate hundreds of HTTP requests. Checking every request manually can take a lot of time, especially when the application has many features and API endpoints.

AI can help review HTTP requests and identify parameters that may refer to user accounts, documents, orders, messages, or other objects.

It can also suggest which requests deserve closer attention. However, AI cannot reliably confirm an IDOR from a request alone. The actual result depends on the application's authorization logic and the server's response.

Here is the six-step workflow I use to organize this process.

Embedded content

Step 1: Set Up Two Test Accounts

The first step is to create two accounts in an application where you have explicit authorization to test access controls.

I will call them Account A and Account B. Each account should contain its own test data, such as a profile, a sample document, or an order created for testing.

Using separate browser profiles can help keep their login sessions independent. This makes it easier to identify which account is making a request and which account owns the object being accessed.

Before testing, record the test data and the expected permissions for each account. This gives you a clear baseline for comparison.

Why does this matter?

IDOR testing is about checking whether one user can access another user's resources without permission. If you do not know which account owns the resource, it becomes much harder to interpret the results correctly.

Step 2: Capture Requests Using Burp Suite

Once both accounts are ready, use Burp Suite to inspect the application's HTTP traffic.

Browse the application normally and pay attention to features that read, create, update, or delete specific resources. These requests often contain useful clues about how the application identifies objects.

For example, you might find requests like these:

• GET /api/users/123
• GET /api/documents/456
• GET /api/orders/789
• GET /api/messages/321
• POST /api/profile/update

These examples are illustrative. Actual endpoints and parameter names vary between applications.

Do not focus only on numbers in URLs. Object references can also appear in query parameters, JSON request bodies, headers, and file names.

For each interesting request, save the HTTP method, endpoint, relevant parameters, and the account used to create the request. This information will help you compare responses later.

Step 3: Use AI to Identify Potential IDOR Parameters

After collecting requests, AI can help identify which parameters might control access to a specific object.

For example, consider this request:

GET /api/documents/456

A parameter such as 456 may identify a document. But an identifier does not automatically mean the endpoint is vulnerable.

The goal is to use AI to build a list of possible test candidates rather than treating every identifier as a confirmed security issue.

You can use a language model to review sanitized HTTP requests and explain which parameters deserve further investigation.

A practical AI prompt

You can adapt the following prompt for your own authorized testing:

Analyze the following sanitized HTTP request for potential broken access control and IDOR risks.

• Identify parameters that may reference users, accounts, documents, orders, messages, or other objects.
• Explain where each parameter appears, such as the URL path, query string, JSON body, or HTTP header.
• Explain what object the parameter may represent and why it deserves attention.
• Suggest a safe test using two accounts that I control.
• Explain what response evidence would support or reject the IDOR hypothesis.
• Identify any missing information that prevents a reliable conclusion.

Before sharing requests with an AI service, remove session cookies, access tokens, passwords, API keys, personal information, and other sensitive values. Follow your organization's rules for handling security data.

Step 4: Review the AI Results Manually

Once the AI identifies possible parameters, review the results before testing them.

Common candidates include user_id, account_id, document_id, order_id, ownerId, and profile_id. These names can provide useful clues, but the application may use different naming conventions.

Object references can also appear in less obvious places, such as nested JSON objects, download links, GraphQL variables, and resource identifiers in API paths.

For each candidate, ask yourself three questions:

• What resource does this value appear to identify?
• Which account should be allowed to access that resource?
• What evidence would show that the server is enforcing the correct permissions?

These questions help separate useful test cases from irrelevant parameters.

For example, a field named user_id might be used only for display purposes. Another field with an ordinary name could control access to a private document.

The parameter name is only a clue. The server's authorization behavior is what matters.

Step 5: Test the Main Parameter Locations

IDOR vulnerabilities can appear in different parts of an HTTP request. Checking only URL parameters may cause you to miss important cases.

Here are the main locations worth reviewing.

1. URL path parameters

Example:

GET /api/users/123

The number may identify a user profile or another resource. Check whether the server verifies that the logged-in account is allowed to access the requested object.

2. Query parameters

Example:

GET /api/documents?document_id=456

Applications often use query parameters to select records, files, reports, or other resources. These parameters should be covered by the same authorization checks as identifiers in the URL path.

3. JSON request bodies

Example:

{"document_id": 456, "title": "Test document"}

When an endpoint updates or retrieves an object, the server must check access to that specific object. It should not trust a client-provided identifier simply because the request came from an authenticated user.

4. HTTP headers

Some applications use custom headers to carry account or tenant information. If a header appears to influence which resource is returned, investigate whether the server validates it against the authenticated user's permissions.

5. File names and resource references

A download feature may accept a file name or document reference. The server must check access to the underlying file rather than assuming that knowing its name grants permission.

Cookies and session tokens require separate care. Never modify authentication credentials or treat a client-controlled identity value as proof of ownership without understanding the application's intended authentication design.

Step 6: Verify the Finding with Burp Suite Repeater

This is the most important step in the workflow.

AI may identify a promising parameter, but only a controlled test can establish whether the application actually allows unauthorized access.

Start with a resource created by Account B. Use Account A's authenticated session to request that resource in your authorized test environment.

For a read operation, compare the original request and the test response. Check whether the returned resource belongs to Account B and whether Account A should have permission to access it.

For an update operation, use harmless test data on a resource you control. Check whether the change is accepted, whether it persists, and whether it affects the intended object.

How to interpret the response

Case 1: The server returns another account's private data

If Account A can retrieve Account B's private document using Account A's own session, and Account A has no permission to access it, that is strong evidence of a potential read IDOR.

Record the original request, modified request, relevant response, and the expected access-control rule.

Case 2: The server denies access

A 403 Forbidden response may indicate that authorization is working correctly. A 404 Not Found response can also be used to avoid revealing whether a resource exists.

However, the status code alone is not enough. Review the response body and the application's expected behavior.

Case 3: The server redirects to the login page

A 302 Found response may indicate an expired session or an authentication requirement. Confirm that the test account is still authenticated before drawing conclusions.

Case 4: The request returns 200 OK

A successful HTTP status does not prove that an IDOR exists. The response might contain public information, an empty result, or a generic success message.

Always verify what data was returned and whether the action actually affected a resource that the user was not allowed to access.

Read IDOR vs. Write IDOR

A read IDOR may expose information belonging to another user. Depending on the data and the number of affected users, this could create a serious privacy risk.

A write IDOR may allow someone to modify another user's profile, document, order, or account settings. Its impact depends on what can be changed and the consequences of that change.

Do not assume that every write vulnerability is automatically more severe than every read vulnerability. Severity depends on the sensitivity of the resource, the permissions required, the practical impact, and the scope of the issue.

Common Mistakes to Avoid During IDOR Testing

Even a good testing workflow can produce false positives if the results are not interpreted carefully.

Here are some mistakes worth avoiding:

1. Treating every identifier as a vulnerability

Applications need identifiers to locate resources. The vulnerability exists when the application fails to enforce the required authorization checks.

2. Trusting AI without verification

AI can misunderstand application logic, suggest irrelevant parameters, or incorrectly interpret responses. Use its output as a starting point, not as proof.

3. Checking only the HTTP status code

A 200 OK response does not necessarily mean private information was exposed. Examine the actual response and verify which resource it represents.

4. Ignoring write operations

Testing only profile and document reads may miss authorization problems in update, delete, and other state-changing actions. Review these operations using controlled test data and safe, reversible changes.

5. Testing without permission

Never use this workflow against systems unless you have explicit authorization and understand the program's scope. Avoid accessing real users' private information or making changes to resources you do not control.

Can AI Automate IDOR Testing?

AI can help with several parts of the process, including identifying likely object references, grouping similar requests, suggesting test cases, comparing response structures, and organizing findings.

Burp Suite's Repeater is useful for controlled manual verification. Its authorization-testing features and extensions may also help compare requests made under different user contexts.

Tools such as PortSwigger's Autorize can assist with authorization testing by replaying requests under different authorization contexts. However, automated results still require review because differences in responses do not always represent real access control failures.

The most reliable workflow combines automation with an understanding of the application's business logic.

For example, an automated tool might identify that a response changed after a parameter was modified. A human tester still needs to determine whether the response contains protected data, whether the test accounts have different permissions, and whether the behavior violates the application's security requirements.

Final Thoughts

IDOR testing is not just about changing an ID and checking whether the server responds.

It requires understanding how resources belong to users, what permissions should apply, and whether the application consistently enforces those permissions. That is why a structured workflow makes such a difference.

AI can speed up the early stages by reviewing requests and identifying potential test candidates. Burp Suite helps you inspect and compare the actual traffic, while manual verification establishes whether the behavior is a real security issue.

My main takeaway is simple: Use AI to find promising leads, use controlled testing to verify them, and use clear evidence to explain their impact.

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