Insecure Direct Object Reference
auth · easy · +25 XP
// what is Insecure Direct Object Reference?
Insecure Direct Object Reference (IDOR) = the server uses a client-supplied identifier (?user_id=42, /orders/1337) to fetch a resource without checking whether the caller is authorised to see it. The classic BOLA (Broken Object Level Authorization) — OWASP API #1 for a reason. Just changing a number in the URL shouldn't unlock someone else's data.
// how attackers detect it
- [01]Look at every request that references your own ID. Try changing it to
1,0,-1,9999999. - [02]Burp Autorize / Autorepeater replays every authenticated request with a second user's session to find leaks.
- [03]Watch for sequential / predictable IDs — UUIDs aren't a fix but they raise the bar.
// how defenders prevent it
- ✓Authorisation check at the resource layer, not in the controller. Pseudocode:
if resource.owner_id != session.user_id: 403. - ✓Use opaque IDs (UUIDs) instead of sequential ints — defense in depth.
- ✓Log every cross-tenant access attempt and alert on bursts (
user A accessed user B's resource).
// real-world incidents
CVE-2023-22515
Confluence Server — IDOR + privesc
Atlassian Data Center mass-exploited Oct 2023.
CVE-2022-29464
WSO2 IDOR → RCE
Identity Server pre-auth IDOR allowed file upload.
// hands-on tips for this lab
- ›Public IDs are 1, 2, 3. Admin is hidden — try
0or negative numbers.
was this lesson helpful?