What Is Broken Access Control? The #1 Web Security Risk Explained

Broken Access Control: The #1 Web Vulnerability

OWASP — the Open Web Application Security Project — ranks **broken access control** as the single most prevalent web application vulnerability. It appeared in 94% of applications tested in their research. If your web app has any concept of users, roles, or permissions, broken access control is a risk you cannot ignore.

What Is Access Control?

Access control is the mechanism that enforces what users are allowed to do in your application. It answers questions like:

- Can this user view this resource? - Can this user modify this record? - Can this user access the admin panel? - Can this user delete another user's data?

When access control is **broken**, users can act outside their intended permissions — accessing other users' data, elevating their privileges, or performing actions they should never be able to.

How Broken Access Control Works

Insecure Direct Object References (IDOR)

The most common form. Your application exposes a direct reference to an internal object — like a database row ID — in the URL or API request, and doesn't verify the requesting user actually owns that object.

**Example:** ``` GET /api/invoices/10482 ```

If invoice 10482 belongs to User A, but User B can also retrieve it just by changing the number to 10482, that's IDOR. The server never checked whether the requesting user has permission to see that invoice.

Read more about [IDOR vulnerabilities](/blog/what-is-insecure-direct-object-reference).

Vertical Privilege Escalation

A normal user accesses functionality reserved for administrators.

**Example:** Your admin panel is at `/admin` and is only linked from the admin dashboard — but there's no server-side check that the requesting user is actually an admin. A regular user who discovers the URL can access it directly.

Horizontal Privilege Escalation

A user accesses another user's data at the same privilege level.

**Example:** User A is logged in. They change their profile URL from `/profile/1001` to `/profile/1002` and see User B's private profile data.

Missing Function-Level Access Control

API endpoints that perform sensitive operations don't verify the caller's permissions.

**Example:** ``` DELETE /api/users/502 ```

This endpoint deletes a user account. The server checks authentication (is the user logged in?) but not authorisation (are they allowed to delete this account?). Any authenticated user can delete any other user.

Forced Browsing

Accessing pages or files that aren't linked publicly but aren't protected server-side either.

**Example:** `/backup/database_export_2026.sql` exists on the server and is publicly accessible because no access check was implemented on that path.

Real-World Impact

Broken access control has been behind some significant breaches:

- **Facebook (2018)** — Access token vulnerability allowed attackers to take over 50 million accounts - **Parler (2021)** — Sequential post IDs with no access control allowed bulk downloading of all content including deleted posts - **Optus (2022)** — An unauthenticated API endpoint exposed 9.8 million Australian customer records

How to Fix Broken Access Control

1. Deny by Default

Every resource and function should be inaccessible unless access is explicitly granted. Never rely on obscurity (hiding a URL) as a security control.

2. Implement Server-Side Authorisation Checks

**Every single request** that touches a protected resource must verify: - Is the user authenticated? - Is the user authorised to perform this action on this specific resource?

Client-side checks (hiding buttons in the UI) are not access controls — they're cosmetic.

3. Use Indirect Object References

Instead of exposing database IDs directly, use GUIDs or map user-specific tokens to internal IDs server-side.

```python # Bad — exposes internal ID GET /invoices/482

# Better — GUID not guessable GET /invoices/7f3d9a2e-4b1c-4e8f-a3d2-9c1e8f2b3a4d ```

4. Log and Monitor Access Control Failures

Log all access control failures. Multiple failures from the same user or IP in a short period indicates an active attack. Alert on anomalies.

5. Test Your Access Controls

Manual testing: log in as User A, capture requests that access User A's resources, replay them while authenticated as User B.

Automated scanning with tools like [Yrzo AI](https://yrzoai.dev) can detect many access control issues including exposed admin paths, IDOR patterns, and unauthenticated API endpoints.

Access Control vs Authentication

These are distinct concepts that get confused:

- **Authentication** — proving who you are (login, session token) - **Authorisation / Access Control** — proving you're allowed to do what you're asking

You can be perfectly authenticated and still exploit broken access control. Most IDOR vulnerabilities require the attacker to be logged in — they just access someone else's data.

Key Takeaways

Broken access control is the #1 web vulnerability for a reason — it's easy to introduce and often overlooked during development. Every route, API endpoint, and file your server exposes needs a server-side authorisation check. Deny by default. Never trust the client. Test as multiple users with different privilege levels.

Run a [security scan on your application](https://yrzoai.dev) to identify broken access control issues before attackers find them for you.