IDOR testing: how pentesters find broken object-level authorization

IDOR stands for insecure direct object reference. It means a user can reach another user's record by changing an identifier in a request. OWASP's API list calls the same class of flaw Broken Object Level Authorization (BOLA), API1:2023. It sits under A01:2025 Broken Access Control in the web Top 10.

OWASP's WSTG defines IDOR this way: it "occurs when an application provides direct access to objects based on user-supplied input." This page covers how we test for it, what proof looks like and how to fix it.

What does an IDOR look like?#

An IDOR needs two things: an object identifier the client controls, and a server that does not check who owns the object. The identifier can be a number, a UUID, a slug or a filename. It can sit in the path, the query string, the JSON body, a header or a cookie.

GET /api/v1/notes/2077 HTTP/1.1
Host: api.harbor-notes.example.com
Authorization: Bearer <token-of-test-user-A>

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 2077, "owner_id": 88, "title": "B private note", "body": "..."}

How do testers prove an IDOR?#

Testers prove an IDOR with two accounts, a controlled request, controls, and a read-back. A single odd response is not proof. Our order is:

1. Create two test-owned accounts in the same role (A and B). Create known data in each, marked as test data. Get written authorization for the scope first.
2. Record the baseline. Fetch B's object with B's token. Save the response.
3. Replay with A's token. Send the same request with A's token. Save the response.
4. Compare. If A receives B's data, the read is broken.
5. Test writes safely. For a write, change only B's test record (for example, a title). Then read it back through B's session. A bare 200 OK is not proof: the read-back is.
6. Run controls. Send a nonexistent ID, A's own ID, B's ID with no token, and B's ID with a token that has a bad signature. Controls that held go in the report.

Where should you look for object references?#

Check every place the client names an object, including routes that nobody tests by hand.

Which test cases matter most?#

Run each case for read, update, delete and any action verb (share, publish, archive).

For multi-tenant products, repeat the matrix between two tenants. The multi-tenant isolation testing guide covers that.

What are common mistakes that hide an IDOR?#

These traps hide an IDOR.

• Trusting the status code. A 200 with an empty body may be a safe empty result. A 404 may be a real object that is hidden only by the front end. Compare bodies and read back.
• Testing only the ID in the path. The same object may be reachable through a body field.
• Using one account. You cannot prove cross-account access from one session.
• Using real customer data. Use test-owned records only.
• Confusing IDOR with enumeration. A response that differs between "exists" and "does not exist" leaks information, but it is a lesser finding than reading the data.

How do teams fix IDOR?#

Fix IDOR with a server-side ownership check on every object access. Do not rely on hidden IDs, front-end checks or route names.

Put the check in one shared place, such as a policy function or a data-access layer, and pass the caller's identity into every query. In pseudo-code:

function getNote(caller, noteId):
    note = db.find(Note, id = noteId)
    if note is null:
        return NotFound
    if not policy.canRead(caller, note):   # owner, shared-with, or role rule
        return NotFound                    # same answer as missing, no leak
    return note

Better, scope the query so a foreign row never loads:

SELECT * FROM notes
WHERE id = :noteId AND tenant_id = :callerTenantId AND owner_id = :callerId;

Apply the same check to list, search, export, batch and file routes, and add an automated test that runs the two-account matrix on every new route. To avoid leaking which IDs exist, return the same status for "missing" and "not yours".

What should you do after a fix?#

Ask for a retest. The retest repeats the original request pair with the same accounts, checks the controls again, and checks the sibling routes, because a fix on one route can miss another.

If your product serves several customers from one database, test tenant boundaries next. Our SaaS penetration testing service covers that, and the API penetration testing page lists what we need to start. For the wider list of API risks, see the OWASP API Security Top 10 guide.

What does an IDOR finding look like in a report?#

A finding gives the developer what they need to reproduce and fix the issue. This illustrative write-up shows the parts.

How do you keep IDOR out for good?#

Fixing one route leaves the next one open, so build the check into the way routes are written.

• One access layer. Route every object fetch through a function that takes the caller.
• Default deny. A new route with no policy should refuse access.
• Tests per route. Add a two-account test to the build for every new object type.
• Review IDs in code review. Any handler that reads an ID from the request needs an ownership line.
• Logging. Log denied object accesses, and alert on a burst of denials by one user.