IDOR & Broken Access Control
Learn broken access control the way it's actually exploited — hands-on, against a live target. Map the attack surface of VaultPay, a fake fintech wallet, then escalate from an ordinary user to the administrator.
What Is an Insecure Direct Object Reference?
An Insecure Direct Object Reference occurs when an application exposes a reference to an internal object — a record, a file, an account — and then trusts the value a user supplies for it without checking whether that user is actually entitled to the object behind it. The application authenticates who you are but forgets to authorize what you may reach.
IDOR is the most common concrete form of broken access control, and it is unusually easy to introduce: the code works perfectly for well-behaved users, and nothing looks wrong until someone changes a value they were never expected to touch. There is no malformed input and no exotic payload — just a legitimate request for someone else's data.
Real-World Impact
Reach a peer's data
Moving sideways to another account at the same privilege level exposes records the application never intended to share. At scale, an enumerable reference can mean the entire user base is readable by any one user.
Reach privileged functionality
When privileged areas rely on nobody guessing the path rather than on an enforced role check, an ordinary user can step up to administrative functionality — the more severe half of broken access control.
Where Broken Access Control Sits in the OWASP Top 10
Broken Access Control is the number one entry in the current OWASP Top 10, having moved up to the top position in the 2021 revision. It earned that rank because it was the most commonly occurring category in the underlying data — access control is enforced in application logic, which means it has to be applied correctly at every single endpoint, and one omission is enough.
| Impact | What the attacker gains | Severity |
|---|---|---|
| Horizontal access | Read or modify a peer user's records | High |
| Vertical escalation | Reach administrative functionality as a normal user | High |
| Unauthenticated data exposure | Retrieve records with no session at all | High |
| Reference enumeration | Walk sequential identifiers to harvest data at scale | Medium |
How PhantomRed Fits Into an Access Control Assessment
Access control is where autonomous scanning hits its natural limit. A scanner can find the endpoints, flag paths that respond when they arguably shouldn't, and map the parameters in play — and Room 5 starts exactly there, with a real PhantomRed scan of VaultPay.
But whether a response is a vulnerability depends on who was supposed to see it, and no scanner knows your authorization model. Confirming IDOR means holding one user's session and reasoning about another user's data. That judgment is the human's:
Access control failures often surface alongside deployment mistakes. The misconfiguration lab covers the exposures that hand an attacker the map in the first place.
Learning Objectives
Concepts
- Why authentication and authorization are separate controls
- The difference between horizontal and vertical escalation
- Why broken access control tops the OWASP Top 10
Hands-On Skills
- Reading a scan report to map an authorization surface
- Identifying object references a user can influence
- Escalating from an ordinary account to a privileged one
Frequently Asked Questions
Related Rooms & Guides
Practice IDOR Against a Live Target
The VaultPay lab is live and free to play. Run a real autonomous scan, map the authorization surface, then exploit the access control failures end to end.