🧪 Labs › Access Control
Insecure Direct Object References (IDOR)
Severity: High
The app checks the number on the door, not whether the door is yours.
What it is
An IDOR is broken access control: the app uses a value you control (an id in the URL, a filename, an account number) to fetch an object, but never checks that the object belongs to you.
Change the reference and you reach someone else's data or actions — read another user's invoice, edit another user's profile, trigger an admin function.
It's one of the most common and impactful web bugs precisely because it hides behind a working feature.
How to approach it
- Find a request that fetches or acts on an object by a reference you can see and change.
- Change the reference to one that should belong to a different user and watch whether authorization is enforced.
- Try sequential, predictable, and guessed references; try changing the reference in the body, the URL, and headers.
- Test state-changing actions, not just reads — the worst IDORs let you act as someone else.
Your task
Access another user's private resource by altering an object reference.
▶ Access the labOpens your hosted RatCTF instance. Work on it directly — there's nothing to submit here; you'll know when you've solved it.
How to prevent it
- Check ownership and authorization on every object access, server-side, every time.
- Prefer references that can't be guessed, but never rely on unguessability as the control.
- Centralise access-control decisions rather than scattering per-endpoint checks.
More Access Control labs
- Broken Object-Level Authorization (BOLA) — An API hands you any record by id — without checking it's yours. IDOR for APIs.
- Broken Function-Level Authorization (BFLA) — A privileged action that only the UI hides — call it directly and it runs.