Broken Access Control in Web Applications

Broken access control happens when an application lets a user act outside their intended permissions, reaching data or functions that should be off limits. It sits at the top of the OWASP Top 10 because the flaws are common, simple to exploit, and often invisible in server logs. A user who changes an ID in a URL and reads someone else’s invoice is broken access control in one sentence. This guide walks through how these vulnerabilities work, real examples like IDOR and privilege escalation, the risks they carry, and the exact controls that shut them down. So where do most teams get authorisation wrong?

Key Takeaways

• Broken access control is an authorization failure: the app verifies who a user is, then fails to enforce what that user is allowed to do.
• It ranks as A01 in the OWASP Top 10 2021, the highest position, after testing found some form of it in 94% of applications reviewed.
• The most common types are IDOR, privilege escalation, forced browsing, and missing function-level access checks.
• Most attacks need only a browser: change an ID, a URL, or a role value, with no special tooling required.
• Prevention starts with deny by default and enforcing every access decision on the server, never in the client.
• A web application firewall and edge controls add a second layer that blocks enumeration and unauthorized probing before it reaches the origin.

What Is Broken Access Control?

Broken access control is a weakness where an application fails to enforce the limits on what an authenticated user can see or do. The user is who they claim to be, but the system still lets them cross into resources or actions meant for someone else.

Access control is the rule layer that decides whether a request should be allowed. When those rules are missing, incomplete, or checked in the wrong place, such as the browser instead of the server, the control is broken. An attacker does not need to steal a password. They ask for something they should not have, and the server hands it over.

Every app guards two things at the door: identity and permissions. Broken access control is a failure of the second. That gap matters because teams often pour effort into login security and multi-factor authentication while leaving the what are you allowed to do checks thin.

Access control shows up in several places across an app:

• URLs and endpoints that map to sensitive functions
• Object references such as record, account, or file IDs
• API routes that change or return data
• Admin features and internal tools
• Static files and downloads tied to a specific user

Teams often assume a hidden or unlinked page is safe. It is not. If the endpoint responds, an attacker can reach it directly, no link needed. Obscurity is not access control. Access control is one layer inside a broader network security solution, and it is the layer attackers probe first because the payoff is so direct.

Before you can fix it, you need to separate two ideas that people constantly blur: authentication and authorization.

Authorization vs Authentication: Why the Difference Matters

Authentication proves who you are. Authorization decides what you are allowed to do. Broken access control is almost always an authorization failure, not an authentication one.

A login form, a password, and an MFA prompt all answer one question: is this really you? Once you are in, a separate set of rules should decide which records, pages, and actions you can touch. When an app checks identity but skips or weakens that permission check, an authenticated user can still reach data that is not theirs.

Picture a hotel. The front desk verifies your identity and hands you a key card, which is authentication. That card should open only your room and the gym, which is authorization. Broken access control is a key card that happens to open every door on the floor.

Authentication can also be undermined after login. If an attacker steals a valid session, a tactic covered in What Is Session Hijacking, they inherit that user’s permissions, which is why strong session handling and solid authorization checks have to work together.

MFA will not save you here. It strengthens authentication, but it says nothing about whether an already authenticated user should reach a given record.

With that split clear, here are the specific shapes broken access control takes in the wild.

Common Types of Broken Access Control Vulnerabilities

Broken access control shows up in a handful of recurring patterns. The most common are insecure direct object references (IDOR), privilege escalation, forced browsing, and missing function-level access control.

Each one has the same root cause: the server trusts something it should verify. The difference is what gets manipulated: an ID, a role, a path, or a token.

• Insecure Direct Object Reference (IDOR): the app exposes an internal key like id=1024 and trusts it without checking ownership. Change the number, read someone else’s record.
• Privilege escalation: a normal user gains rights they should not have, either horizontally into another user’s data or vertically into a higher role.
• Forced browsing: reaching restricted pages or endpoints directly by guessing or already knowing the URL.
• Missing function level access control: the interface hides an admin action, but the API behind it has no server-side role check.
• Metadata and token tampering: altering a cookie, hidden field, or JWT claim, for example, flipping role: user to role: admin.
• CORS misconfiguration: trusting the wrong origin, so another site can make authenticated calls on a user’s behalf.

The scariest of these is not the exotic one. It is the boring sequential ID, because it takes zero skill to exploit and it hides inside apps that otherwise look secure. These patterns are easier to grasp once you watch one play out end to end.

Real-World Broken Access Control Examples

A real-life example of broken access control is changing the account number in a URL to view another customer’s data. Banking, healthcare, and SaaS apps have all shipped this exact flaw.

Three examples show how ordinary the flaw looks in practice:

• The classic IDOR: a request to /api/user/1024/profile. Swap 1024 for 1025, and the server returns a stranger’s profile, because it never confirms the logged-in user owns record 1025.
• Privilege escalation through a hidden field: a form that posts role=customer. An attacker intercepts the request, sets role=admin, and the backend trusts the value.
• Forced browsing to an admin panel: /admin/exports is not linked anywhere, yet it loads for any logged-in user because the page never checks for an admin role.

The scale is not theoretical. Broken access control was the most serious web application risk in the OWASP Top 10 2021, and testing found some form of it in 94% of applications. Data exposure incidents tied to IDOR and missing authorization checks keep surfacing across fintech and health platforms.

So why is a bug this simple treated as the number one web risk?

The Risks of Broken Access Control

The risks of broken access control run from stolen personal data and account takeover to full administrative compromise and regulatory penalties. Because the flaw grants direct access, the damage is immediate.

A single unchecked endpoint can expose an entire customer table. Once an attacker confirms one record leaks, they script the rest. That turns a small oversight into a breach that carries legal, financial, and reputational weight.

• Mass data exposure, by enumerating record IDs and scraping at scale
• Account and privilege takeover, up to full admin control
• Unauthorized transactions or data changes
• Compliance violations and fines under GDPR, HIPAA, and PCI DSS
• Silent breaches: requests look valid, so logs show HTTP 200, not an alarm

Detection is harder than it sounds, because the traffic looks normal. Pairing application logs with Custom IP Lists helps you spot a single client walking through hundreds of record IDs, a pattern that stands out even when each individual request looks legitimate.

Enumeration is fast. A script iterating IDs can pull tens of thousands of records in minutes, which is why a leak often becomes a full database dump before anyone notices. You might assume a small app is not a target, but automated scanners do not care about size. They probe every reachable endpoint, and sequential IDs light up instantly.

To defend against it, you first have to see how an attacker actually pulls it off.

How a Broken Access Control Attack Works

A broken access control attack usually needs nothing more than a logged-in session and a bit of curiosity. The attacker takes a legitimate request, changes one value- an ID, a role, or a path- and the server complies because it never checks ownership or role.

The steps rarely change:

1. Authenticate normally with a real, low-privilege account.
2. Capture a request that references an object, such as /account?id=1024.
3. Modify the reference, for example, id=1025, or role=admin, or an /admin path.
4. Replay the request and read or change data that belongs to someone else.
5. Automate the change across a range of values to scrape or alter records at scale.

The request returns HTTP 200 OK, and that success code is the trap. Nothing errors, nothing logs as suspicious, and the app behaves exactly as it was coded to. The vulnerability is not a crash. It is correct behavior running on a broken rule.

Automated enumeration often comes from scripts and bots that rotate IP addresses to dodge blocks. Techniques like JA3 fingerprint identify a client by its TLS handshake, so you can flag the same tool even when it hops between addresses. And because the attack depends on replaying many similar requests, Rate Limiting on sensitive endpoints slows enumeration to a crawl and buys your detection systems time to react.

Knowing the attack pattern points straight at the fix.

How to Prevent Broken Access Control

You prevent broken access control by denying access unless it is explicitly granted, enforcing every decision on the server, and tying each request to the identity and ownership of the caller.

All of these fixes share one rule: do not trust the client. A browser can be modified, intercepted, and replayed. Only the server has the context to decide, on each request, whether this exact user should touch this exact resource.

• Deny by default. Every endpoint starts closed and opens only for authorized roles.
• Enforce access control on the server, never in the browser. Hidden UI is not security.
• Check ownership on every object, not just the role. Confirm the caller owns record 1025 before returning it.
• Use a clear model: role-based access control (RBAC) or attribute-based (ABAC), applied consistently across every route.
• Avoid exposing raw, sequential database IDs. Use unpredictable references or strict per-user checks.
• Log access decisions and alert on anomalies like rapid ID enumeration.
• Test authorization automatically, so a new endpoint cannot ship without an access check.

For files and shared resources, replace guessable paths with a secured link that expires and ties access to a specific user or time window, so a leaked or altered URL simply stops working. Application logic is your first defense, but a customized WAF lets you write rules that block obvious tampering, such as requests that flip a role parameter or hit admin paths without the right context. Access control also benefits from firewall integration, so policy decisions at the application layer line up with network-level rules instead of fighting them.

Yes, input validation and encryption matter, but they do not stop broken access control. You can validate and encrypt a request perfectly and still hand over data the user was never allowed to see. Authorization is a separate control, and it needs its own attention.

Application fixes close the hole. Edge controls make sure attackers cannot keep knocking.

How a WAF and Edge Security Mitigate Broken Access Control

A web application firewall and edge security do not replace server-side authorization, but they add a strong second layer, filtering unauthorized probing, tampering, and enumeration before it ever reaches your origin.

A WAF inspects application layer traffic, so it understands HTTP requests, not just packets. That means it can act on the exact behavior broken access control relies on: manipulated parameters, requests for sensitive paths, and traffic from clients that already look malicious.

• Block parameter tampering and suspicious admin path access with targeted rules
• Throttle enumeration with rate limits on object and account endpoints
• Identify and stop automated tools even when they rotate IP addresses
• Apply allow and deny policies for the most sensitive functions
• Absorb the volumetric noise attackers use to mask targeted probing

An advanced web application firewall inspects each HTTP request and can reject the ones that tamper with roles, IDs, or paths. That catches a whole class of broken access control attempts at the edge. The WAF vs Firewall distinction matters here: a network firewall filters packets and ports, while a WAF reads the application request itself, which is the exact layer where broken access control lives. Attackers also bury targeted enumeration inside a flood of traffic, so pairing access controls with advanced DDoS mitigation keeps that noise from overwhelming both your defenses and your logs.

Layered like this, broken access control moves from your single biggest risk to a managed one.

Broken Access Control and the OWASP Top 10

In the OWASP Top 10 2021, broken access control moved to the number one position, listed as A01, up from fifth in the previous edition. OWASP ranked it first because it was the most common serious issue found across tested applications.

OWASP folded several older categories, including some IDOR and access-related issues, under A01. Across the applications reviewed, some form of broken access control appeared in 94% of them, and the category maps to a large set of underlying weakness types.

OWASP’s own guidance aligns with the fixes above: deny by default, enforce access on the server, disable directory listing, log access failures, and rate-limit APIs to blunt automated abuse.

The jump to number one was not because the flaw suddenly got worse. It got better measured. Stronger testing simply confirmed how widespread it already was.

Final Thought on Broken Access Control

Broken access control is common because it is easy to overlook and easy to exploit, yet it is also one of the most fixable risks on the OWASP list. The core idea is simple: decide what each user is allowed to do, enforce that decision on the server for every request, and deny anything you have not explicitly allowed.

Treat authorization as a first-class part of your design, not a checkbox at the end. Pair solid server-side checks with edge protection that filters probing and enumeration, and test those controls the same way you test features. Do that, and a flaw that tops the threat charts becomes a routine part of how you ship.

Frequently Asked Questions About Broken Access Control