OWASP Top 10:2021 — A01: Broken Access Control

Welcome to the first post in this OWASP Top 10:2021 series, where I break down each of the top security risks. This is for engineers who may not be security pros (yet), but want to understand where vulnerabilities hide, how attackers think, and how to build more secure applications.

Let’s start with the #1 risk on the list: Broken Access Control.

Full series:

1. A01: Broken Access Control (you are here)
2. A02: Cryptographic Failures
3. A03: Injection Attacks
4. A04: Insecure Design
5. A05: Security Misconfiguration
6. A06: Vulnerable and Outdated Components
7. A07: Identification and Authentication Failures
8. A08: Software and Data Integrity Failures
9. A09: Security Logging and Monitoring Failures
10. A10: Server-Side Request Forgery (SSRF)

What is Broken Access Control?

Access control is about making sure that users can only do what they’re supposed to do—nothing more, nothing less.

Broken Access Control happens when those checks are missing, misconfigured, or easily bypassed. It’s like locking the front door of your house but leaving the side window open. An attacker doesn’t care how they get in.

Examples include:

• Regular users accessing admin-only functions.
• One user viewing or editing another user’s data just by changing a URL or ID.
• Public APIs that expose sensitive operations without proper authentication or authorisation.

Why Does This Happen?

There are a few common reasons this vulnerability sneaks in:

• Over-reliance on frontend checks: Hiding an “admin” button in the UI doesn’t stop a savvy attacker from calling the endpoint directly.
• Inconsistent access rules: If your logic isn’t centralised, different parts of your app might enforce different (or no) rules.
• Misconfigured roles and permissions: Often, roles are added late in development and not fully tested.
• Missing authorisation on APIs: A REST endpoint might accept a request without confirming whether the user has permission to make it.

How Attackers Exploit It

Attackers love broken access control because it often gives them high-impact results with low effort.

Here are some real-world exploitation tactics:

• IDOR (Insecure Direct Object References)

Changing a URL from /account/1234 to /account/1235 to view someone else’s data.

• Forced browsing

Discovering hidden admin routes like /admin/config that aren’t protected on the backend.

• Token manipulation

Modifying or replaying session tokens to impersonate users or escalate privileges.

• Method tampering

Sending unauthorised POST, PUT, or DELETE requests to endpoints that lack proper checks.

What Engineers Can Do

This is where we turn from red-team to blue-team thinking. Here’s how to prevent broken access control in your apps:

1. Server-Side Authorisation Is Non-Negotiable
   • Never rely solely on client-side logic. Always validate permissions server-side on every request.
2. Use Role-Based Access Control (RBAC)
   • Assign roles like user, moderator, admin, and define what each can and cannot do. Keep your role logic centralised so it’s consistent across services and endpoints.
3. Deny by Default
   • Your app should assume a user has no permissions unless explicitly granted. This limits accidental overexposure.
4. Secure API Endpoints Like You Secure Web Routes
   • APIs are a common blind spot. Treat them with the same level of access control scrutiny.
5. Log Violations and Monitor
   • Track failed access attempts. A high number of 403s or unauthorised requests can be early warning signs of probing or attack attempts.

Real-World Example: The “Oops, That’s Not My Account” Bug

Let’s say you’re working on a fintech app, and users can view their account details at /accounts/{id}.

If the backend doesn’t confirm that the logged-in user owns that account ID, then someone could easily:

1. Log in.
2. Change the ID in the URL to guess another user’s account.
3. And suddenly see someone else’s financial details.

That’s broken access control—plain and simple, and very dangerous.

Final Thoughts

Broken access control isn’t always flashy, but it’s often devastating. It’s responsible for serious breaches across nearly every industry, and it’s the most commonly exploited issue on the OWASP list.

If you only remember one thing from this post: Always validate permissions server-side, and never assume the client can be trusted.

Next up in this series: A02: Cryptographic Failures → We’ll look at what happens when encryption is done wrong—or not at all—and how to get it right.