IDOR: how to spot broken object-level authorization

IDOR: how to spot broken object-level authorization

TL;DR

If your API returns someone else's data when you swap an ID in the URL, you have an IDOR bug. The test is simple: with two test accounts, request account B's object using account A's credentials. Getting B's data back means the endpoint trusts the ID without checking ownership. The fix is always server-side: verify the caller owns (or may access) the object on every request.

IDOR: how to spot broken object-level authorization

Use this when

• You are testing or reviewing an API for access-control bugs
• A pentest or bug bounty report mentions IDOR or "broken object level authorization"
• Your API uses predictable IDs in URLs (sequential numbers, UUIDs in paths)
• You want a repeatable test to run against every object endpoint

Not for this skill when

• The bug is about which fields get written (that is mass assignment, a different skill)
• You need function-level auth (who can call admin endpoints; related but separate)
• You are testing someone else's API without permission (get authorization first)
• You want automated scanning only (scanners miss logic bugs; manual testing finds them)

Steps

1. Map the object references

List endpoints that take an object ID: /api/orders/[id], /api/accounts/[id]/documents, and the same IDs inside request bodies. Predictable sequential IDs are the easiest to test; UUIDs are testable too, you just need two known IDs.

grep -rnE "orders/|/documents" src/routes/ | head -20

Expected: a list of endpoints with the ID parameter marked for each. Include nested routes; /api/teams/[team-id]/members/[member-id] has two IDs to test, and bugs love the second one.

2. Set up two test users with known objects

Create user A and user B, each owning at least one object. Record both object IDs. Use dedicated test accounts in a test environment, never real users.

printf 'user A owns order [id-A]\nuser B owns order [id-B]\n' | tee idor-test-accounts.txt

Expected: two accounts, A and B, each with an object the other must not see. The whole test is swapping the IDs.

3. Request B's object with A's credentials

The core test. Authenticate as A, request B's object ID, and look at what comes back.

curl -s https://example.com/api/orders/[id-of-B] -H "your auth header -o /dev/null -w "%{http_code}"

Expected for a secure endpoint: 403 or 404. For a vulnerable endpoint: 200, which confirms the bug. Whether to use 403 or 404 is a design choice (404 leaks less about what exists); either is acceptable, 200 with B's data is not.

4. Test the write side too

Read-IDOR gets the attention, but write-IDOR (updating or deleting someone else's object) is worse. Repeat the swap with PUT, PATCH, and DELETE.

curl -s -X PATCH https://example.com/api/orders/[id-of-B] -H "your auth header --request-json '{"note":"probe"}' -o /dev/null -w "%{http_code}"

Expected: 403 or 404 again. Then fetch B's object as B and verify it is unchanged. A 200 here means account A can modify account B's data; treat it as critical.

5. Fix with a server-side ownership check

On every object access, load the object and verify the caller's relationship to it before returning or mutating anything. The check lives in the API, not the frontend, and it runs on every request, not just the "sensitive" ones.

order = get_order([order-id])
if order.owner_id != current_user.id:
    raise Forbidden("not your object")

Expected: the probes from steps 3 and 4 now return 403 or 404, and legitimate owners still get 200. Add both probes as regression tests so the check cannot be silently dropped later.

Variant: UUIDs and unguessable IDs

Unguessable IDs are obscurity, not authorization. Test exactly the same way with two known IDs; if the endpoint returns B's object to A, the UUID only slowed the attacker down. Fix it the same way.

Variant: IDs in request bodies instead of URLs

Some APIs take the object ID in the JSON body. Swap it there too; body IDs get less review attention and are buggier on average. Same fix: check ownership server-side regardless of where the ID arrived.

Variant: bulk and list endpoints

Test list endpoints for cross-tenant leakage: as A, list objects and confirm none of B's appear. Test bulk actions with a mixed list of your IDs and B's IDs; the endpoint must reject or skip the ones you do not own, not process them all.

Why this happens

Developers check authentication (are you logged in) and forget authorization (may you touch this object). The endpoint loads the object by ID and returns it; nothing in that flow asks about ownership unless someone wrote the check. It is especially common in endpoints added later ("just fetch by ID, the frontend only links your own") and in nested routes where the parent ID is checked but the child ID is not. Frameworks do not do this for you; ownership is application logic only you can express.

Edge cases and pitfalls

• Inconsistent 404 vs 403: pick one and apply it everywhere; mixed behavior lets attackers map which IDs exist.
• Shared and delegated access: "owner or someone the owner shared with" is still a check; model the sharing explicitly instead of skipping the check for "flexibility".
• Admin endpoints need the check too, scoped to the admin's permitted set; "admins can see everything" should be a deliberate policy, not an accident.
• Caching: a cached response for B's object served to A bypasses the check; key caches by user or check before serving.
• Do not "fix" IDOR by making IDs unguessable alone; that is a speed bump, and speed bumps are not authorization.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_U7Ze87wX7PQXhyeWdO0YbQ