← All lessons
Web attacks · Beginner · 3 min
Broken access control & IDOR
Change one number in the URL and see someone else's data.
What it is
Access control decides who can see and do what. It's #1 on the OWASP Top 10 because it's easy to get wrong. The classic version is IDOR (insecure direct object reference): /invoice/1001 is yours, and changing it to /invoice/1002 shows a stranger's because the app never checks ownership. Others include normal users reaching admin pages or APIs that trust whatever role the browser claims.
Real case · 2022
Optus
Australia's second-largest telco lost personal data on almost 10 million current and former customers. It was widely reported that an internet-facing API needed no login and used sequential customer IDs, though Optus disputed how simple the attack was.
Source: Wikipedia: 2022 Optus data breach
How defenders stop it
- Check permissions on the server for every request
- Deny by default
- Use unpredictable IDs (but never rely on that alone)
- Test with two accounts: can user A see user B's things?
Check yourself
1. Using random IDs instead of 1001, 1002 fully fixes IDOR. True or false?
- True
- False
Show answer
False. It makes guessing harder, but the real fix is checking ownership on every request.
2. Changing /invoice/1001 to /invoice/1002 shows a stranger's invoice. What's the bug?
- A DDoS attack
- SQL injection
- Cross-site scripting
- IDOR: the server never checks who owns the record
Show answer
IDOR: the server never checks who owns the record. This is an insecure direct object reference: the app trusts the ID in the URL instead of checking ownership.
3. Where must permission checks happen?
- On the server, for every request
- Only on the login page
- In the browser's JavaScript
- In the page's URL
Show answer
On the server, for every request. Anything in the browser is under the user's control. Only the server can be trusted to decide who sees what.
Answer them in the app to earn XP.
Next: Networking basics →