IDOR is an access control vulnerability where the application trusts user-controlled identifiers (IDs) to fetch objects (profiles, invoices, tickets) without verifying ownership or authorization on the server side.
High signal: if changing an ID returns another user's data, you likely found an IDOR.
Common patterns:
/profile?user_id=1305/api/v1/customer/1305{"id":1305}Core check: the server must validate authorization (is this object allowed for this session?) not just authentication.
The fastest detection method: change the identifier and observe if the response changes to another user/object.
Example:
/profile?user_id=1305 → /profile?user_id=1000
Some apps encode IDs (commonly base64). Decode → modify → re-encode → resend.
Exam note: encoding is reversible; hashing is not.
Hashed identifiers may be predictable (e.g., md5 of an integer). Always try common cracking databases first.
Example: if the app uses md5, 123 → 202cb962ac59075b964b07152d234b70
If IDs are random/UUID-like, create 2 accounts and swap IDs between requests.
/api/...)Example pattern: /api/v1/customer?id={user_id}