The IDOR checklist: how to test for insecure direct object references

An IDOR checklist is a repeatable set of checks for one question: when a signed-in account changes an identifier in a request, does the server still return or change data that belongs to someone else? To test it, use two accounts, replay each request that carries an ID with the other account's ID, and compare the responses. If the second account gets a 200 and the first account's data, you have an IDOR.

The hard part is finding every place an identifier hides, then recording each result so a developer can fix it and a tester can prove the fix.

What is IDOR?

Insecure direct object reference means the application uses an identifier supplied by the client to fetch or change an object, and never checks that the caller is allowed to touch that object. The OWASP IDOR Prevention Cheat Sheet names three ingredients: an object, a reference to it (an ID, UUID, token or slug) and a missing object-level authorisation check. Remove any one and the bug disappears.

The classic case is /invoices/1042 changed to /invoices/1043. The user is authenticated, so the request passes the login check, but nothing asks whether invoice 1043 is theirs. PortSwigger also shows the file version: /static/12144.txt changed to another number.

IDOR is not a separate family from other access-control bugs. It sits inside broken access control, which is number one (A01) in the OWASP Top 10:2025 and maps to CWE-639, Authorization Bypass Through User-Controlled Key. In API terms the same flaw is called BOLA; the BOLA post covers the naming difference and the code-review angle.

How common is IDOR?

IDOR sits inside the most common class of web flaw. In the OWASP Top 10:2025, A01 Broken Access Control is still number one, with an average incidence rate of 3.74%, a maximum of 20.15%, 40 mapped CWEs and 1,839,701 occurrences in the contributed data. CWE-639, the IDOR weakness, is one of the 40.

The 2025 CWE Top 25 shows the same family from another angle. CWE-862 (Missing Authorization) ranks fourth with a score of 13.28, and CWE-639 ranks 24th with a score of 2.62.

It is also cheap to find. The OWASP API Security Top 10 (2023) rates API1, BOLA, as easy to exploit, widespread and easy to detect, with moderate technical impact. Older bounty data agrees: HackerOne reported in 2021 that IDOR made up 36% of vulnerability bounties in medical technology and 31% in professional services.

Is IDOR the same as BOLA?

Yes, in practice. IDOR is the older web name for the bug and BOLA is the OWASP API name for it; both map to CWE-639.

The three terms overlap. Pick the one your audience expects and keep the evidence the same.

• IDOR is the older web term. It describes the mechanism: a direct reference the client controls.
• BOLA is the name used by the OWASP API Security Top 10 (2023), where it is risk number one. It describes the missing check at object level.
• Horizontal privilege escalation describes the effect: one account reaching a peer's data. When the same trick reaches an admin function, it becomes vertical privilege escalation.

In a report, use whichever name the client's team searches for, then add the CWE and the OWASP reference so the finding maps cleanly to audits.

What do you need before you test for IDOR?

Most IDOR testing fails at setup, not at the request. You need accounts that own different objects, and you need to know which objects belong to whom.

1. Create at least two accounts of the same role (call them A and B). This tests horizontal access.
2. Add one account of a lower role and one of a higher role. This tests vertical access, such as a member reaching an admin object.
3. If the product is multi-tenant, create two tenants with at least one account each. Cross-tenant IDOR is the version that ends up in a customer's security questionnaire. See tenant isolation.
4. Have each account create real objects: an order, a file, a message, a saved card label, an invite. Write down every ID created, with its owner.
5. Use a test environment with realistic data, not production, unless you have written permission and a plan for the data you will touch.

Keep a simple access plan as a table: object type, who owns it, who may read it, who may change it, who may delete it. Every row becomes a set of test cases. The access control testing checklist shows how to build that plan in more depth.

Where do object IDs hide in an application?

People who only look at the address bar miss most IDORs. Build the list of identifiers from the whole traffic log, not from the page you can see. Walk through the app with a proxy running and tag every value that looks like a reference.

In the request

The table lists the request locations to tag while you click through the app with a proxy running.

In the response and in quieter places

• Lists that return objects with IDs you did not own before, plus links to downloads, exports and signed URLs.
• Error messages, logs and email notifications that print or link to other IDs.

Features that get less review

• Background features: PDF exports, CSV downloads, report generators, email previews, "share" links, webhooks you can register.
• Search and autocomplete endpoints that return records before any access filter is applied.
• Old API versions and routes that the interface no longer calls but the server still serves. This is where a shadow API or zombie API hides.

How do you test for IDOR? The checklist, step by step

Run this loop for every request that carries an identifier. It is the core of IDOR testing and matches the OWASP Web Security Testing Guide (WSTG-ATHZ-04), which advises at least two users who own different objects and functions, so you can try one account's references from the other.

1. Capture the request as account A, on an object A owns. Save the full request and response.
2. Swap the identifier for one owned by account B. Keep A's session token. Send it.
3. Compare. A 403 or 404 with no data is a pass. A 200 with B's data is a finding. A 200 with an empty body needs a second look: some apps return the same shell page whether or not the object exists.
4. Test every verb, not just GET. Try PUT, PATCH, POST and DELETE on B's object. Reads often work the way they should while writes slip through.
5. Test the same call with no session at all. If it still returns data, the problem is wider than IDOR: see unauthenticated access.
6. Test a lower role against a higher role's object, and a user from tenant 1 against tenant 2.
7. Test the child objects. Parent checks are often right and child checks are not: an order may be protected while /orders/8841/items/3, its invoice PDF or its comments are open.
8. Test creation. When A creates a record, can the request set an owner or tenant field to B? That is a mass assignment issue that ends as IDOR.
9. Record the outcome as a pass, a fail or "not applicable", with the request, the response and the two account names.

Which operations should you test on each object?

Run the swap on every operation an object supports. The table shows what to send and what a pass looks like.

What do you try when the simple swap is blocked?

Developers often block the obvious change and miss the neighbours. These variations catch the second layer of mistakes.

Change the shape of the identifier

Try these variations

• Send two values. ?id=A_ID&id=B_ID can pass a check on the first value and return the second. This is HTTP parameter pollution.
• Send an array where a single value is expected: {"id": [A_ID, B_ID]}.
• Wrap the value in an object, or switch the content type between JSON, form and XML if the endpoint accepts more than one.
• Add wildcards or special values such as *, 0, -1 or an empty value, and see whether the endpoint returns a list instead of one record.
• Change the extension or format: /orders/8841.json may skip middleware that protects /orders/8841.

Change the route

Try these routes

• Try the same object through a different verb or path, for example a legacy /v1/ route next to /v3/.
• Call internal-style routes the front end never uses, such as /admin/orders/8841. That edges into forced browsing.
• Replay the request with me replaced by an explicit ID, or an explicit ID replaced by me.

Change what the server trusts

• If the identity comes from a JWT claim, check that the server uses the signed claim and ignores a user ID in the body. The mitigation advice under CWE-639 comes down to one habit: authorise every single data access against the specific record being asked for.
• If a header such as X-Tenant selects the tenant, try changing it. Tenant headers set by a gateway should never be accepted from the client.

Do UUIDs and encoded IDs stop IDOR?

No. UUIDs and encoded IDs make guessing harder, but only a server-side ownership check stops IDOR. The test changes from guessing an ID to learning one and replaying it.

Switching from numbers to UUIDs makes enumeration harder. It does not add an authorisation check. The OWASP cheat sheet agrees that complex identifiers are hard to guess, then insists the access control check still has to exist. The API Security Top 10 likewise lists random GUIDs beside a proper authorisation mechanism, never instead of one. See unguessable IDs.

So the test changes. You no longer guess the other account's ID. You obtain it, then use it.

How to obtain an identifier you were not given

• Read it from an endpoint that lists or searches shared objects: team directories, comments, activity feeds, public profiles.
• Read it from an email, a share link, an export file or a webhook payload.
• Read it from an error message, a log view or the page source.
• Use account B's own ID, which you know because you created B. In a real test this is the strongest evidence, because nothing was guessed.

If a value looks random, check. Base64 around a number, a hex integer, an MD5 of an email address or a version 1 UUID (which embeds a timestamp) can all be predicted. If the app signs the value, change one character and confirm the server rejects it.

How do you test IDOR in REST and GraphQL APIs?

APIs expose the object model directly, which is why OWASP puts object-level authorisation first. The API security testing post walks through the full list; these are the IDOR-specific points.

• Use the OpenAPI file or a recorded session to list every route with an ID. Check them with a script, not by hand.
• Bulk and batch endpoints. POST /orders/lookup with a list of IDs may check the first and return all. Put one of your IDs first and one of B's second.
• Nested routes. /teams/5/members/9 may check team 5 but not whether member 9 belongs to it.
• Filters and expansions. ?include=owner, ?fields= and ?expand= can return related objects that were never authorised on their own.
• GraphQL. Query the same node by ID through different fields. A resolver at the top may check ownership while a nested field does not. Test mutations as well as queries, and check batched operations.
• Pagination and search. A list endpoint that returns a page of other users' records is IDOR without any ID being changed.

How do you test IDOR in mobile apps, files and exports?

Mobile and file features often get a lighter review than the web interface, though they call the same back end.

• Mobile apps. Route the app's traffic through a proxy and run the same swap on every call. Apps often hold hard-coded API versions and older routes. Check deep links too: a link that opens app://invoice/8841 must still ask the server who is allowed to read it.
• File downloads. Predictable filenames such as /uploads/12144.pdf are the oldest IDOR. Check whether object storage URLs are public by default and whether signed links expire.
• Multi-step flows. Check that step three re-checks the owner, instead of trusting an ID set at step one.

What should an IDOR finding record?

A finding that the developer can reproduce in one go gets fixed. A vague one gets argued over. Record:

1. The exact request, with the session identified by account name and role, and the object ID used.
2. The response, with the part that proves exposure highlighted (the other account's name, email or amount).
3. Who owned the object, so the reader knows no guess was involved.
4. The verbs that worked: read, update, delete.
5. Impact in one line: what the data is, and how many records could be reached if the ID space is enumerable.
6. A screenshot where a person can see it in the interface.
7. In a white-box test, the file and line where the lookup skips the check.

Keep severity and confidence apart. A read-only exposure of low-sensitivity data and a delete on every customer's invoices are both IDOR, but they are different severities. The read a finding post explains the four-part finding, and severity versus confidence covers the split.

How do you fix IDOR?

Fix IDOR on the server, where the data is fetched: make the owner part of every lookup and deny by default. Hiding or randomising IDs is an extra layer, not the fix.

Fix patterns that hold up

Fixes that work put the check where the data is fetched. Fixes that fail hide the identifier and leave the lookup alone.

Check on the server, on every access

The ownership check must run for each read, update and delete. The IDOR cheat sheet points the same way: when you fetch an object by its key, search only among the objects this caller may use. An object outside that set simply does not exist as far as the caller is concerned.

Scope the query, not the response

Do not fetch the record and then decide whether to show it, if you can avoid it. Add the owner or tenant to the query itself. In databases that support it, row-level security enforces the same rule below the application, so a forgotten check in one route cannot expose data.

Take identity from the session

For "my" resources, do not accept a user ID from the client at all. Read it from the session or the validated token. Strip owner and tenant fields from create and update bodies, which also closes the mass assignment route.

Deny by default

New routes should refuse access until a rule says otherwise. The A01:2025 prevention advice includes deny by default for everything non-public, one shared access-control layer, and record ownership built into the data model. A shared helper or middleware that every handler must call is safer than a check copied into each handler.

Use unguessable IDs as an extra layer

Random identifiers reduce scraping and make enumeration noisy. Add them after the check exists. Do not rely on secrecy of the ID, because IDs leak through links, logs and lists.

Where the existence of an object is itself sensitive, return the same status for "not yours" and "not there".

How do you stop IDOR coming back?

IDOR returns when someone adds a route. The OWASP Authorization Testing Automation Cheat Sheet blames the usual cause: releases add or change features and nobody checks what that does to authorisation. The remedy is a test that fails when a check goes missing.

1. For each route with an ID, write a test with two accounts. Account A creates the object. Account B requests it. Expect a denial and no data in the body.
2. Run it for read, update and delete.
3. Generate the list of routes from your router or OpenAPI file, so a new route without a test is flagged.
4. Run the tests in CI/CD and fail the build on a missing denial. See security regression test.
5. After a reported IDOR, replay the exact original request against the fix. This is a closed-loop retest: the same exploit, now failing. A new scan that finds nothing does not prove the old request is closed.

A regression test per object type

Keep one row per object type in your test suite.

Can scanners and code review find IDOR?

Scanners work well at known patterns and badly at ownership. A DAST tool with one login cannot tell that account B's invoice is exposed to account A, because it has no second account to compare. Why your scanner has one login explains this gap, and exploited, not suspected explains why proof matters.

Code review fills the gap. When you review a handler, ask: where does this ID come from, what query uses it, and what ties the result to the caller? A lookup that takes only the ID is the signal. The same pattern is easy to search for in code, and white-box testing uses it: read the code to find the lookups, then test the running app to confirm which ones really expose data. See white-box testing and the comparison of the three approaches.

What mistakes make IDOR tests miss bugs?

• Testing only GET. Writes and deletes are usually the bigger finding.
• Testing only the visible page. Exports, mobile and old API versions are separate routes.
• Using an admin as the second account. Admins are meant to see everything, so the test proves nothing.
• Stopping at the first fix. The same lookup pattern probably exists in other handlers.
• Testing once a year. New routes ship weekly; pair a yearly test with automated checks, the VAPT checklist and the web application checklist.

For a broader view of related flaws that surface beside IDOR, such as pricing and workflow abuse, see the business logic testing checklist. For proof from real findings, visit evidence, and for how a test runs end to end, how it works.