Glossary
Insecure direct object reference (IDOR)
A flaw where an application uses an ID from the request to fetch data without checking that the caller is allowed to see it.
Also called Broken object-level authorization, BOLA.
In plain terms
If changing /documents/1041 to /documents/1042 shows you someone else’s document, that’s an IDOR. The server trusted the ID and skipped the question of who owns the object.
It’s one of the most common serious API flaws because it’s invisible in normal use. Every request works fine until someone tries an ID that isn’t theirs.
See what happens without it
The failure pattern this protects against, cross-tenant access through a caller-controlled identifier, played out step by step.
Scroll the diagram sideways to see every system.
Bob’s invoice is returned to Alice.
What goes wrong:
- Alice opens her invoice at /invoices/1041.
- She edits the number in the address bar to 1042.
- The API trusts the ID from the request and never checks who owns it.
- Bob’s invoice is returned to Alice.
With the safeguard:
- Alice opens her invoice at /invoices/1041.
- She edits the number in the address bar to 1042.
- The API scopes every query to the tenant of the signed-in user.
- No match means 404. Guessing IDs reveals nothing.
When it mattered
In 2019 a document portal at First American exposed more than 800 million mortgage-related images, because changing a number in a link revealed other customers’ files.