IDOR, insecure direct object reference, is an access-control flaw where changing an identifier in a request lets you read or modify data that belongs to someone else. The server trusts the ID and never checks that the logged-in user may access that object.
Example
After logging in you open /invoice/1042. Changing the number to /invoice/1041 shows another customer's invoice, and one of them contains the flag. The fix is a server-side check that the invoice belongs to the current user, not hiding or randomizing the ID.
GET /api/notes/2 -> your note
GET /api/notes/1 -> someone else's note (the bug)Where to look
- Numeric IDs in URLs, JSON bodies and cookies.
- Download and export endpoints.
- Actions as well as reads: edit, delete, change email.
- Base64 or hex wrapped IDs, which decode to plain numbers. The encoder and decoder helps here.
On CTF7
Web challenges with a backend run as isolated lab instances, so you can change IDs without disturbing other teams. In Raw Ops, the same class of bug is reported as a vulnerability and scored by severity with CVSS 4.0.
Learn more
Read the web exploitation guide for worked examples and tools, or browse all CTF guides.
Related terms
Browse the full CTF and cybersecurity glossary for more terms.
