Broken access control: what it is and why it is missed
Changing a number in the address and seeing someone else's order. Why access control fails so often, where it hides, and how it is tested properly.
The short answer
Access control is the rule that a user may see and change only what belongs to them. It breaks in a specific, common way: the site checks that you are logged in and then forgets to check that the thing you asked for is yours. Change the number in the address of your own order and you see someone else’s. Change it again and you see a third. It is the most frequent serious finding in applications with logins, and because it exposes other people’s data, it is the kind of incident that has legal consequences.
No automated scanner finds it, because no scanner knows whose order 1042 is.
Where it hides
| Pattern | Example |
|---|---|
| Predictable identifiers in the address | /orders/1042, /invoices/2026-0311, /documents/88 |
| Checks only on the page, not on the data | The orders page shows only yours; the order detail shows anyone’s |
| Hidden links treated as protection | The admin page is not linked, but it loads for anyone who knows the address |
| Missing checks on write actions | You cannot see another user’s profile, but you can change it by submitting the form with their id |
| Downloads and files | A document behind a login, served from a public address once you know it |
| Roles trusted from the browser | A role sent by the client, editable by the client |
Why it is so common
Building the happy path is natural: log in, see your things. The failure is in every other request, where a developer assumed that a user would only ever ask for their own data because the interface only shows their own links. Attackers do not use the interface. They change numbers, replay requests with other identifiers and submit forms they were never shown.
How it is tested properly
- Two accounts. Create two ordinary users with their own data.
- Log in as the first, capture requests. Every address and every form that touches data.
- Replay them with the second user’s identifiers. Orders, invoices, documents, profile changes, downloads.
- Try the admin paths as an ordinary user. Every address that staff use.
- Check write actions, not just reads. Change, delete, approve, with the other user’s ids.
Anything that succeeds is a finding. This is a manual test, and it is a standard part of the penetration testing we recommend for any system with logins.
How it is built right
Every request that touches data checks, on the server, that the logged-in user may access that specific record, using the user’s identity from the session rather than anything the browser sent. Identifiers are not relied on to be secret. Roles are stored and enforced server-side. Files behind a login are served through a check, never from a public address. Tests with two accounts are part of the build, not an afterthought.
What this means for you
If your business runs anything with logins, ask whether every data request checks ownership on the server and whether it was tested with two accounts. Vague answers mean the test has not been done. It is the single most valuable security test for an application, it cannot be automated, and the alternative is a customer telling you they saw someone else’s invoice.
Frequently asked questions
Our site checks that users are logged in. Isn't that enough?
Logged in answers 'who are you'. Access control answers 'may you see this particular thing'. A logged-in customer who can open another customer's invoice by changing a number has passed the first check and exposed the failure of the second. Both are required, on every request.
Why do scanners not find this?
Because a scanner does not know your rules. It cannot tell that order 1042 belongs to someone else. Finding broken access control needs a person with two accounts, trying to reach the second account's data from the first. That is a core part of a proper penetration test.
Does a static website have access control problems?
Not on its pages, which are the same for everyone. Any portal, account area, download behind a login or function that returns data per user does, and those are exactly the parts worth testing with two accounts before launch.
Sources
- OWASP Cheat Sheet: Authorization (accessed 2026-09-11)
- OWASP Top Ten (accessed 2026-09-11)