Broken Access Control & IDOR
TL;DR
Broken Access Control is the number-one web risk: the app lets a user reach data or actions that should be off-limits. IDOR — changing an id in a request to see someone else’s data — is the classic example. The fix is to check authorisation on the server for every request, every time.
Only test apps you own or are authorised to test.
What it is
Access control decides who can do what. When those checks are missing, weak, or only enforced in the UI, users can step outside their lane: read other people’s records, hit admin functions, or change things that aren’t theirs.
How it works
The most common shape is IDOR (Insecure Direct Object Reference). A request references an object by id — /account?id=1043 — and the server returns it without checking whether this user should see that object. Change the number, get someone else’s data. The same idea covers “forced browsing’ to admin URLs and actions hidden only by not showing a button.
How to test for it
- Log in as a low-privilege user and note requests that reference ids or names.
- Swap those references for another user’s (or another number) and see if the data comes back.
- Try reaching admin-only pages and actions directly as a normal user.
- Two accounts side by side (one low, one high) makes this quick to prove.
How to fix it
- Enforce authorisation on the server for every request — never trust the client to hide things.
- Check ownership: does this user own, or have rights to, the object they’re asking for?
- Deny by default, and prefer unguessable identifiers as defence in depth (not as the only control).
Reference: OWASP A01: Broken Access Control.