Insecure Direct Object Reference (IDOR)
CWE-639: Authorization Bypass Through User-Controlled Key
This is the weakness most testers call insecure direct object reference (IDOR). The application uses an identifier supplied by the user, such as an account number, order id, or document id, to look up a record, and does not check that the record belongs to the requester. Changing the identifier gives access to someone else's data. Sequential numeric ids make it trivial to enumerate, but random ids alone are not a fix.
Ranks change between editions as the underlying CVE data changes, so exam questions rarely hinge on an exact rank. Know what each weakness is, how it is exploited, and how it is prevented.
How it shows up in the real world
- Changing /api/orders/10452 to /api/orders/10453 returns another customer's order and delivery address.
- A document download link uses ?doc=8812, and incrementing the number exposes other users' statements.
- A mobile API accepts a userId field in the request body and updates whichever profile it names.
How to mitigate it
- Check ownership or permission for every object access on the server, ideally by scoping the query to the caller's user or tenant.
- Use the authenticated session to determine whose data to return instead of trusting ids in the request where possible.
- Use unpredictable identifiers such as UUIDs as defence in depth, not as the access control itself.
- Test every object-level endpoint with two accounts to confirm one cannot read or modify the other's records.
Go deeper
Practice this topic
Test your knowledge of Insecure Direct Object Reference (IDOR) with exam-style practice questions.