Access control decides who is allowed to do what inside your application. When those rules are missing, incomplete, or easy to bypass, the result is broken access control: a person reaching data or actions that should never have been available to them. It sits at the very top of the industry's most-cited list of web application risks, and for good reason. It is common, it is easy to introduce without noticing, and the damage is immediate.
What broken access control actually looks like
The phrase sounds abstract, but the real cases are very concrete:
- Changing an ID in a web address, for example from
/invoice/1024to/invoice/1025, and seeing another customer's record. - An interface that hides an admin button from ordinary users, while the underlying API never actually checks permissions when the request arrives.
- A database left open so anyone can read a table, which is broken access control at the data layer.
- A standard user reaching an admin-only page simply by typing its address directly.
- An account that can edit its own role or permissions and quietly promote itself.
In each case the application trusts something it should not: the browser, the hidden button, or the assumption that nobody will guess the next ID.
Why it is so common, especially in fast-moving products
Access rules are spread across every endpoint in your application. Each new feature adds another place where a check can be forgotten, and it only takes one missed check to expose data. Modern frameworks and AI coding tools scaffold features quickly, but they rarely enforce authorisation for you, so the gaps are easy to miss when you are moving fast. The default in many stacks is that a route or record is reachable unless you explicitly lock it down, which means the safe path requires deliberate effort on every feature.
How to find and fix it
Broken access control is rarely fixed by a single patch. It is a discipline applied consistently across the application.
Enforce every check on the server. Hiding a button or a link in the interface is presentation, not security. The server must independently confirm that the current user is allowed to perform the action, on every request.
Deny by default. Start from the position that access is refused, then grant it explicitly to the roles that need it. This turns a forgotten rule into a locked door rather than an open one.
Check ownership on every record. Before returning or changing an object, confirm that it actually belongs to the requesting user. This is the single most effective defence against the "change the ID in the URL" class of issue.
Centralise your authorisation logic. Repeating ad hoc permission checks in dozens of places guarantees that one will eventually be wrong. A single, well-tested layer is far easier to reason about.
Test as different roles, including no login at all. Walk through sensitive actions as an administrator, as an ordinary user, and as an anonymous visitor, and confirm each is stopped where it should be.
The Open Worldwide Application Security Project (OWASP) ranks broken access control first in its 2025 list of web application risks, and its guidance is a reliable reference point for the patterns to watch for. As always, finding an issue is only half the job: each finding needs to be verified, fixed at the root, and retested before the risk is actually reduced.
What an automated external check can and cannot see
It is worth being clear about the limits of automated scanning here. A passive, external tool such as our free Surface Check can tell you what your application exposes to the public internet, such as security headers, TLS, cookie flags, and email spoofing protection. What it cannot do is judge whether your authorisation logic is correct, because that lives inside your application and depends on your business rules. Broken access control is precisely the kind of flaw an external pass will miss. Use an automated check as a quick first look at your surface, not as a verdict on who can reach what inside your product.
Next steps
Getting access control right is one of the highest-value things a product team can do for its security, and it is also one of the easiest to get subtly wrong. If you would like a second pair of eyes on how your application handles permissions and data access, our application security assessment is built for startups and fast-moving teams. We prepare the fixes and hand them to your team to review and deploy, or apply them directly where you have authorised us to do so in writing. You can get in touch through our website.