Log in as one customer, change a single number in the address bar, and see another customer’s invoice. No hacking tools needed — and it is the most common serious flaw we look for in web apps.
Why this matters to your business
It is the most common serious web weakness, and it usually exposes real customer data — the kind of incident that triggers breach reporting and lost trust.
What is broken access control?
Access control decides who can see or do what: a customer sees only their own orders, a staff member cannot approve their own refund, a normal user cannot open the admin page. When those checks are missing or can be bypassed, access control is broken.
It is ranked A01 — the top category — in the OWASP Top 10, because it is both very common and often leads straight to data exposure.
What does it look like in practice?
Changing an ID in a link or API call and getting someone else’s record. Opening an admin URL directly without being an admin. Editing a hidden field to change your role, price or account. Using a token after logout that still works.
Why do scanners and normal testing miss it?
The app is working exactly as coded — it just never asks “does this record belong to you?”. Finding these gaps needs testing with several real accounts and roles, comparing what each one can reach.
How do you prevent it?
Deny by default, check ownership and role on the server for every request, never trust IDs or roles sent by the browser or app, and add automated tests that try to read another user’s data so the check cannot quietly disappear in a later release.
Where should you look first?
Anything that shows or changes a specific record — invoices, statements, profiles, orders, documents — and every admin or support function. Mobile apps deserve the same attention, because their APIs are often less protected than the website.
Key takeaways
- A01 in the OWASP Top 10 for a reason.
- The app works as coded — the check is missing.
- Check ownership on the server for every request.
Jargon buster
- Access control
- The rules that decide who can see or do what in an app.
- IDOR
- Insecure Direct Object Reference: getting someone else’s data by changing an ID.
- Deny by default
- Blocking everything unless a rule clearly allows it.
What you should do
- Deny access by default
- Check ownership and role on the server
- Never trust IDs or roles sent by the client
- Add tests that try to read another user’s data
What our team does
- Test with several accounts and roles
- Try every object ID and admin route
- Prove each issue with a safe request
- Retest after your fixes
- Compare what each role can reach, side by side
- Test the APIs behind your mobile apps too
Want to know if one account can see another’s data? That’s the first thing we test.
— The CRIS InfoTech security team