We’re at the halfway point in our series on the OWASP Top 10 — the ten most common and most damaging categories of web application weakness. There’s still a lot of confusion about how these issues actually work and what you can do about them, and the explanations you find online tend to assume you’re already an expert. At Rootsec, we’d rather keep things clear and jargon-light, so anyone can follow along. Today we answer the question: what is broken access control?
This one deserves your attention more than most. In the current OWASP Top 10 (2021), “A01: Broken Access Control” sits right at the top of the list — the most serious category of all. That’s a notable jump: in the 2017 edition it was ranked A5, and it has since climbed to number one as more and more breaches were traced back to it. In other words, this is exactly the kind of weakness worth understanding properly.
What is broken access control?
Access control — sometimes called authorisation — is all about how a web application decides which users are allowed to reach which content and functionality. It’s the layer that separates users who should have far-reaching rights (administrators, say) from those who shouldn’t. Crucially, this check happens after authentication — that is, after someone has logged in — and it determines what those “authorised users” are actually permitted to do.
A simple way to picture it is to think of passing through immigration at the airport. Logging in is like showing your passport: it proves who you are. Access control is the next question — do you hold a valid visa, and if so, what does it actually allow you to do, and for how long? Proving your identity and being granted permission are two very different things.
In theory this sounds straightforward. In practice it’s one of the trickiest things to get right. Every application has its own mix of content and functions, and its own groups of users with different levels of privilege, so there’s no one-size-fits-all rulebook. Developers often underestimate just how involved this gets. The result is that access rules end up scattered piecemeal throughout the code rather than being designed in a structured, deliberate way — an ad-hoc collection of checks that’s hard to follow and easy to get wrong. And when access control is implemented inconsistently, gaps appear.
What are the consequences of broken access control?
The uncomfortable truth is that flawed access control is often not very hard for an attacker to find or exploit. They simply send requests for content or functions they shouldn’t be able to reach — for example, by changing a value in a web address, or by calling a function that was never meant to be exposed to them. When one of those requests succeeds, the weakness is laid bare.
From there, the consequences range from bad to serious. At one end, an attacker might be able to view content they were never authorised to see. Worse, in many cases they can go further and modify or delete data, perform actions reserved for other users, or even gain control over the administration of the site. It’s worth stressing that this isn’t a niche problem: web servers, application servers, and web application environments of all kinds are susceptible, and even largely static sites can be exposed if they’re misconfigured.
What can you do about broken access control?
The single most important thing you can — and should — do is to think carefully about your application’s access control requirements before you build it, rather than bolting them on afterwards. In practice, that breaks down into a few clear steps:
- Evaluate your requirements thoroughly. Work out exactly which types of users exist, and which functions and content each of them should be able to reach.
- Write it down. Capture those decisions in an application security policy, so the rules are documented rather than living in someone’s head.
- Use an access control matrix. A simple grid mapping user roles against permissions makes the intended rules explicit and easy to review.
- Test before you go live. Check your access controls actively — ideally by trying to bypass them — so that gaps are caught before an attacker finds them.
- Validate your inputs. Define clearly what each parameter is allowed to contain, so values can’t be tampered with to slip past your checks.
The pattern here is the same one we see again and again: prevention starts with a good policy, followed by a careful implementation. It’s something that is, on paper, genuinely simple — and yet it still goes wrong remarkably often. That’s exactly why a fresh pair of expert eyes pays off. A penetration test puts your access controls through the same checks a real attacker would, surfacing the gaps before they can be abused.
At Rootsec, our goal has always been to make information security simple and approachable — and this series is part of that mission.
Not sure whether your access controls would hold up against a real attacker? A Rootsec penetration test finds out first. Book a free consultation.
