Insecure Direct Object References (IDOR)

Insecure direct object references (IDOR) happen when an app exposes a direct reference to an object — ?id=123, a filename, a UUID — and authorizes the action (is this user logged in?) but not the object (does this user own record 123?). Change the reference and you get another user’s data back. It’s a form of broken access control, commonly combined with CSRF to target a specific victim, and it’s usually surfaced alongside XSS findings during a web app test.

Common Techniques

Sequential-ID enumeration — increment or decrement a numeric ID to walk through other users’ records.
Predictable-GUID guessing — identifiers that look random but follow a derivable pattern.
Method / verb tampering — an endpoint checks authorization on GET but not on PUT/DELETE for the same object.
Mass-assignment cousins — extra fields in a request body get bound to an object the user shouldn’t control.
Horizontal vs. vertical escalation — accessing a peer’s data (horizontal) versus an admin-only object (vertical).

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Testing

Authenticate as two low-privilege test users, capture an object request as user A, then replay it as user B — or with A’s session against B’s neighboring IDs:

GET /api/invoices/1042   (as user A, expected)
GET /api/invoices/1041   (as user A, replayed)

A 200 returning another tenant’s data — instead of a 403/404 — confirms IDOR. Note the endpoint, the identifier pattern, and the exposed data in the pentest report so the fix can be scoped to every affected route, not just the one you found.

Remediation

Enforce object-level authorization on every request, server-side, checking that the authenticated user actually owns or is granted the requested object — never trust the client’s reference alone. Prefer unguessable, ownership-checked references over sequential IDs, default to deny, and centralize the access-check logic so it can’t be skipped on a new route.