IDOR / Broken Access Control

An IDOR (Insecure Direct Object Reference) is an access-control flaw: the application exposes a direct reference to an internal object (an id, a GUID, a filename) and fails to check that the requesting user is entitled to that object. By changing the reference, the attacker accesses other users' data or actions. It is the most common form of Broken Access Control, number one in the OWASP Top 10.

The pattern

Endpoints like /api/v1/user/1, /invoice?id=42 or /download?file=... where simply incrementing or substituting the identifier is enough:

curl -s http://<ip>/api/v1/user/1 -H "Authorization: Bearer <token>" | jq   # another user's data?
curl -s http://<ip>/api/v1/user/2 -H "Authorization: Bearer <token>" | jq

When the id is not sequential but a UUID/GUID, the IDOR is still alive if that identifier leaks in another response (a listing, a hidden field, a header). The trick is to harvest IDs from one place and reuse them where they should not be valid.

Beyond reading

An IDOR is not limited to reading. If the leaked identifier is reused to authorize another operation, the impact multiplies: in Backend, the admin's GUID obtained via IDOR was exactly what the /updatepass endpoint used to decide whose password to change, which allowed taking over the admin account without knowing its password. Nearby variants:

• Method tampering: replay the request with PUT/DELETE/PATCH when the GET is protected but the other verbs are not.
• Mass assignment: add unexpected fields to the JSON ("role":"admin", "isAdmin":true) that the backend accepts without filtering.
• Forced browsing: reach guessed admin routes (/admin, /api/internal) that are only hidden, not protected.

How to find them and automate

Compare responses while varying identifiers, watch for UUID values that look secret but leak, and review every sensitive action asking "does the server validate that this object is mine?". To scale the sweep, Burp Intruder walks ranges of id and the Autorize extension replays each request with a lower-privilege user's session and flags those that should not respond.

Requirements

A client-controllable object reference and a backend that does not re-authorize per object. No session privilege escalation is needed: the flaw is that the session you already have reaches other people's objects.

How to detect it. The server sees a user accessing objects that do not belong to them, sequentially or in bulk: many requests to /user/1, /user/2, /user/3... from one session, or an account reading/editing resources of other IDs in a short time. The signature is the mismatch between the authenticated subject and the owner of the requested object, which is only detectable if the app logs both. 200 responses to other people's objects, or a spike of 403/404 from forced browsing, are the signals in the log.

Defence. Enforce authorization on the server for every object and action (do not trust the id coming from the client), use per-session indirect references, and do not expose identifiers that later serve to authorize. Related to credential reuse when the IDOR leaks reusable secrets and to API information disclosure.