IDOR via predictable IDs: a logic bug dressed as auth

Insecure Direct Object Reference (IDOR) sounds like "broken access control" because it is — but in bug bounty programs it often shows up as perfectly valid UUIDs in URLs and APIs that never ask "does this user own this object?"

The pattern

request.http

1GET /api/v1/invoices/7c9e6679-7425-40de-944b-e07fc1f90ae7 HTTP/1.12Authorization: Bearer <user-a-token>

User A's token. User B's invoice ID. If the response is 200 with B's PDF, you have IDOR — not "UUID guessing," just missing authorization.

Why UUIDs don't save you

UUIDs are identifiers, not secrets. They leak in emails, analytics, referrers, and browser history. Security through obscurity fails the moment one ID crosses a trust boundary.

How to hunt it

timeline

Create two accounts — low-privilege "victim" and your tester account.

Capture object IDs from the victim session (export, share link, notification email).

Replay requests from the tester session with the victim's IDs.

Mutate verbs — `GET` might be locked down while `PATCH` or `DELETE` isn't.

The fix

Authorize on every handler

owns: object ownership

resolve resource → owner tenant/userdeny by default

Middleware auth ≠ resource auth. Check ownership *after* you load the row.

Opaque IDs at the edge

owns: public references

signed tokens / capability URLsseparate internal vs external IDs

Defense in depth — but never skip server-side checks.

For a network-layer cousin of "trust the wrong boundary," see SSRF walkthrough.