What is Broken Access Control?

Definition

Broken access control is the failure of an application to enforce restrictions on what authenticated users are allowed to do. When access controls are broken, a user can access data, modify records, or invoke functions that should be restricted to other users, roles, or the application itself.

Broken access control ranked number one in the OWASP Top 10 2021 — up from number five in 2017. It is the most prevalent web application security risk: 94% of applications tested by OWASP contained at least one access control failure. It is also among the most impactful, because access control failures often lead to full data breaches.

Types of Broken Access Control

Insecure Direct Object Reference (IDOR)

An application exposes a reference to an internal object — a database ID, a file path, an account number — and does not verify that the requesting user is authorized to access that object. An attacker changes the ID in the URL to access another user's data.

Vertical privilege escalation

A low-privilege user accesses functionality intended for higher-privilege users. For example, a regular user accessing admin panels by guessing the URL, or calling an API endpoint that does not verify the caller's role.

Horizontal privilege escalation

A user accesses another user's data or functionality at the same privilege level. Retrieving another user's account details by changing a user ID parameter.

Missing function-level access control

The application hides UI elements from unauthorized users but does not enforce restrictions on the underlying API. A user who finds or guesses the endpoint URL can still access it.

Metadata manipulation

Tampering with access control tokens, JWTs, cookies, or form fields to elevate privileges or bypass restrictions.

Real-World Impact

Access control failures have caused some of the largest data breaches in recent years. Common scenarios:

• Incremental IDs in API URLs expose all records to enumeration
• Admin endpoints without role verification accessible to any authenticated user
• File download endpoints that serve any file by path without ownership checks
• Multi-tenant applications that fail to scope queries to the current tenant

Prevention

Deny by default

Access should be denied unless explicitly granted. Every route, endpoint, and resource should require proof of authorization — not just authentication. The default is no access, not full access.

Enforce access control server-side

Client-side access control (hiding buttons, filtering UI) is not a security control. Access must be enforced on the server for every request, regardless of what the client shows.

Object-level authorization checks

For every request that accesses a specific object by ID, verify that the authenticated user owns or has permission to access that object. Do not rely on the assumption that only legitimate users know legitimate IDs.

Use role-based or attribute-based access control frameworks

Implement a centralized access control model (RBAC, ABAC) rather than scattering permission checks across the codebase. Centralized enforcement is auditable and consistent.

Broken Access Control and Autonomous Code Governance

Hydra detects broken access control patterns by analyzing route definitions, middleware chains, and controller logic — identifying endpoints that are authenticated but lack authorization checks, or that accept user-supplied IDs without ownership validation. These patterns are detectable through static analysis of the request-handling pipeline. Fixes add the appropriate authorization checks at the framework level, matching the patterns used elsewhere in the codebase.