Insecure Direct Object Reference (IDOR) is one of the oldest classes of web vulnerability and still one of the most commonly reported in bug bounty programs. It’s simple to explain, easy to introduce, and easy to miss in review — which is exactly why it persists.

01 — What it actually is

An IDOR happens when an application exposes a reference to an internal object — a database row, a file, a user ID — and lets a client control that reference without properly verifying the requester is authorized to access it.

GET /api/invoices/1042

If changing 1042 to 1043 returns someone else’s invoice without an object-level authorization check, that’s an IDOR.

02 — Where it hides

• REST endpoints using sequential or predictable IDs
• File download endpoints with missing ownership checks
• Admin panels where role checks exist but object-level checks don’t
• GraphQL resolvers that fetch by ID without re-validating scope

03 — How to test it

With proper authorization on an engagement, map endpoints that accept identifiers. For each one, use test accounts with different ownership and compare the server’s response. UUIDs make enumeration harder, but they do not replace authorization.

04 — Fixing it

Every object-returning endpoint needs an explicit server-side ownership or permission check. The check must be enforced independently of whether the identifier is sequential, random, or otherwise difficult to guess.