Category: Vulnerability Management
Broken Access Control
Also known as: Access Control Failure, Improper Access Control
Simply put
Broken access control is a security flaw that occurs when an application fails to properly restrict what actions users are allowed to perform based on their permissions. This can allow unauthorized users to access, modify, or delete data or functionality they should not be able to reach. It is one of the most common and impactful categories of web application vulnerabilities.
Formal definition
Broken access control arises when an application's enforcement of authorization policies is incomplete, bypassable, or absent, such that authenticated or unauthenticated users can perform operations or access resources outside their intended privilege boundary. Failure modes typically include insecure direct object references, missing function-level access controls, privilege escalation (both horizontal and vertical), and improper authentication of users prior to authorization checks. Because access control logic is often distributed across multiple application layers and depends on runtime context (such as session state, resource ownership, and role assignments), static analysis alone is typically insufficient to identify all instances. Comprehensive testing requires multiple accounts with differing privilege levels and active probing of access control enforcement across application states.
Why it matters
Broken access control is consistently ranked among the most prevalent and severe vulnerability categories in web application security. It moved to the top position in the OWASP Top 10 in 2021, reflecting how frequently applications fail to properly enforce what authenticated or unauthenticated users are permitted to do. Unlike many vulnerability classes that require sophisticated exploitation techniques, access control failures can often be exploited with minimal technical skill by simply manipulating URLs, API parameters, or session identifiers to reach resources or functions that should be restricted.
Who it's relevant to
Application Developers
Developers are responsible for implementing server-side authorization checks at every access point, including API endpoints, data retrieval functions, and administrative operations. Common mistakes include relying on client-side controls, assuming hidden URLs are inaccessible, or implementing access checks inconsistently across an application. Developers should enforce access control at the server layer, apply deny-by-default policies, and treat all user-supplied identifiers as untrusted input that must be validated against the current user's permissions.
Security Engineers and Penetration Testers
Security engineers and penetration testers bear primary responsibility for identifying broken access control before and after deployment. Effective testing requires accounts at multiple privilege levels, systematic enumeration of object references and API routes, and verification that server-side enforcement exists independently of any interface-level restrictions. Automated scanners may surface some indicators, but they typically cannot replicate the contextual reasoning needed to confirm privilege escalation or horizontal access violations across all application states.
Product and Application Security Managers
Product and application security managers should ensure that access control requirements are defined explicitly during design and validated throughout the development lifecycle, not treated as an implementation detail left to individual developers. Because access control logic tends to be distributed and is often added incrementally as features are built, it is prone to gaps when there is no centralized policy or review process. Managers can reduce risk by mandating role-aware testing in acceptance criteria and establishing clear ownership for authorization policy across application layers.
Compliance and Risk Professionals
Broken access control is directly relevant to regulatory requirements governing data access and user privacy, including frameworks that require organizations to limit data access to authorized parties only. Compliance professionals should recognize that access control failures can result in unauthorized exposure of personal, financial, or health data and may trigger breach notification obligations. Risk assessments should account for the difficulty of detecting access control failures through standard monitoring, given that unauthorized access may not produce errors or anomalous traffic patterns.
Inside Broken Access Control
Vertical Privilege Escalation
A failure that allows a user to access functionality or data reserved for higher-privilege roles, such as a regular user performing administrative actions by manipulating requests directly.
Horizontal Privilege Escalation
A failure that allows a user to access resources belonging to another user at the same privilege level, typically by manipulating identifiers such as user IDs or account numbers in requests.
Insecure Direct Object Reference (IDOR)
A specific pattern of broken access control in which an application exposes internal object references (such as database record IDs or filenames) that an attacker can manipulate to access unauthorized resources without server-side authorization checks.
Missing Function-Level Access Control
A condition in which the application fails to enforce authorization checks on sensitive functions or endpoints, relying instead on the assumption that users will not discover or directly request those endpoints.
Path Traversal
An access control failure in which an attacker manipulates file path inputs to access files or directories outside the intended scope, potentially exposing sensitive system or application files.
Forced Browsing
A technique in which an attacker directly requests URLs or resources that are not linked in the application interface but are not protected by server-side authorization, allowing access to restricted content.
Access Control Policy Enforcement Point
The server-side mechanism responsible for evaluating and enforcing authorization decisions on every request. Broken access control typically arises when this enforcement is absent, inconsistent, or bypassable.
Metadata Manipulation
An attack vector in which an attacker tampers with access control tokens, cookies, hidden fields, or JWT claims to elevate privileges or impersonate other users or roles.
Common questions
Answers to the questions practitioners most commonly ask about Broken Access Control.
Does fixing broken access control just mean adding authentication to endpoints?
No. Authentication and access control are distinct concerns. Authentication verifies who a user is, while access control determines what an authenticated user is permitted to do. Broken access control refers to failures in the authorization layer, such as users accessing resources or performing actions beyond their intended privileges, even after they have successfully authenticated. Adding login requirements does not address whether the correct authorization checks are enforced on each action or resource.
Can automated scanning tools reliably detect broken access control vulnerabilities?
Only partially. Automated scanners can identify some surface-level indicators, such as missing authentication headers or directory listing exposure, but broken access control vulnerabilities are largely logic-dependent. Because correct access decisions depend on the relationship between a specific user, their role or attributes, and the resource being requested, automated tools typically cannot reason about whether a given permission decision is appropriate. Most broken access control findings require manual testing, including attempts to access resources across different user roles or privilege levels, to confirm whether controls are enforced correctly.
How should access control checks be implemented in a web application?
Access control checks should be enforced server-side on every request, regardless of any client-side restrictions that may also exist. The server should verify that the authenticated user has the required permission for the specific resource or action being requested, not merely that the user is logged in. Checks should not rely on obscurity, such as hiding URLs or using non-guessable identifiers as a substitute for authorization. Centralized access control logic, applied consistently across all routes and endpoints, reduces the risk of gaps caused by inconsistent per-endpoint implementation.
What is the difference between vertical and horizontal privilege escalation in the context of broken access control?
Vertical privilege escalation occurs when a user gains access to functionality or resources intended for a higher privilege level, such as a regular user accessing administrative functions. Horizontal privilege escalation occurs when a user accesses resources belonging to another user at the same privilege level, such as viewing or modifying another user's account data by manipulating a resource identifier. Both are manifestations of broken access control, but they require different testing strategies and may involve different underlying control failures.
How should insecure direct object references be mitigated?
Insecure direct object references, a common form of broken access control, occur when an application exposes internal identifiers such as database keys in URLs or parameters without verifying that the requesting user is authorized to access the corresponding resource. Mitigation typically involves enforcing an ownership or permission check on the server for every request that references a resource, confirming that the authenticated user is permitted to access that specific record. Using indirect reference maps or opaque identifiers may reduce guessability but should not substitute for authorization checks, as they do not prevent access by users who obtain a valid reference through other means.
What testing approaches are most effective for identifying broken access control?
Effective testing typically combines role-based access testing, where requests are made as users with different privilege levels to confirm that lower-privileged users cannot access higher-privileged resources, with horizontal access testing across users at the same privilege level. Testers should attempt to manipulate request parameters, path segments, and identifiers to reference resources belonging to other users or outside the authenticated user's scope. Reviewing access control logic in source code can identify missing checks, but functional testing with active sessions representing distinct user roles is generally necessary to confirm that enforcement is correct at runtime.
Common misconceptions
Hiding or obscuring URLs and functionality is sufficient to prevent unauthorized access.
Security through obscurity does not constitute access control. Without server-side authorization checks on every request, any endpoint that exists can potentially be discovered and accessed directly, regardless of whether it is linked in the user interface.
Client-side access control checks, such as disabling buttons or hiding menu items in the browser, effectively prevent unauthorized actions.
Client-side controls can be trivially bypassed by an attacker using a proxy or by crafting direct HTTP requests. Authorization decisions must be enforced on the server side for every request, independent of what the client presents.
Broken access control is reliably detectable through automated static analysis or vulnerability scanning alone.
Automated tools can identify some patterns, such as missing authorization annotations or certain IDOR signatures, but access control logic is heavily context-dependent. Determining whether a given user should be permitted to access a specific resource typically requires understanding business rules and application context that static or automated tools cannot fully evaluate. Manual review and runtime testing are generally necessary to identify access control failures comprehensively.
Best practices
Enforce authorization checks server-side on every request, including for API endpoints and direct object references, rather than relying on client-side controls or the assumption that sensitive URLs will not be discovered.
Adopt a deny-by-default access control model in which access to any resource or function is explicitly granted, and all other access is denied by default, reducing the risk of unintentionally exposed functionality.
Use indirect object references or access-controlled mappings rather than exposing raw internal identifiers such as database primary keys, and validate on the server side that the authenticated user is authorized to access the specific resource being requested.
Implement and consistently apply a centralized access control mechanism across the application rather than scattering authorization logic throughout the codebase, which reduces inconsistency and makes auditing more tractable.
Conduct regular access control testing that includes manual review and role-based test cases covering both vertical and horizontal privilege escalation scenarios, since automated tools typically cannot fully evaluate business-logic-driven authorization rules.
Log and monitor access control failures, including repeated denied requests or anomalous access patterns, to support detection of active exploitation attempts and to inform ongoing improvements to authorization policy.