The $0 bug that leaks your whole user table: IDOR, explained simply

IDOR — Insecure Direct Object Reference — is the vulnerability that makes people say "wait, that's it?" There's no clever payload. You change a number in a URL and the server hands you data that isn't yours.

How it happens

Picture an endpoint like this:

GET /api/users/1042

The controller takes 1042, looks it up, and returns the record. It works perfectly in every demo. The problem is what it *doesn't* do: it never checks whether the person asking is actually user 1042.

So an attacker logs in as themselves, opens dev tools, and starts counting: 1043, 1044, 1045. Every request returns someone else's profile. No alarm goes off, because from the server's point of view these are all valid, authenticated requests.

Why scanners flag it but teams miss it

Static analysis can spot the *shape* of the problem — a database lookup keyed on a client-supplied id with no authorization call nearby. What it can't always tell you is how bad it is in *your* app. That depends on what's behind the endpoint.

That's the context our AI engineer adds. For the demo API it traced the path end to end:

Internet → public API → `/api/users/:id` → missing authorization → customer records.

Once you can see the whole path, the severity is obvious and the fix is small.

The fix is almost always boring

• Check ownership on every object lookup: does this user own, or have a role that permits, this resource?
• Prefer scoping queries to the session (where user_id = :current_user) over trusting an id from the request.
• Use unguessable identifiers where you can, but treat that as defense in depth — not a substitute for the authorization check.

IDOR is cheap to exploit and cheap to fix. The expensive part is finding out about it from a customer instead of a scan.