IDOR testing

What it means

IDOR testing is the check for insecure direct object references. A tester takes a request that fetches or changes a record, such as GET /invoices/1042, and replays it with an id that belongs to someone else, or with another account's session, to see whether the app notices.

The core of the method is two accounts. Account A owns records, account B is a different customer. If B can read or change A's records, the app has a flaw. If the app answers with a denial, it passed that case.

Why it matters

It is the easiest way to prove cross-customer exposure, and the results are plain: a screenshot of one account showing another account's data. That helps a team agree on severity, and it is the kind of evidence a customer or auditor trusts.

Automated scanners usually miss these flaws, because they cannot tell whose data they are looking at. A manual or logic-aware test is needed, repeated whenever endpoints change, since a new route is a new chance to forget the check. Re-run it whenever a release adds routes.

How it shows up

The test touches every place an id appears: path segments, query strings, request bodies, headers, cookies, GraphQL variables and file download links. Also try each method on the same path, since GET may be guarded while PUT and DELETE are not.

Good testers also look for ids in other places than the obvious one: a list that reveals them, an email link, an export. They test numeric, UUID and encoded ids, and ids in nested objects. A pass means the server refuses for all of these. A fix is a server-side ownership check on every lookup.