# OWASP Top 10: Broken Access Control
Broken access control is the most frequently confirmed vulnerability class in modern web applications, ranked first in the OWASP Top 10 since 2021. It occurs when an application correctly identifies who a user is but fails to enforce what that user is permitted to do. Authentication asks "who are you?" Authorization asks "what are you allowed to do?" Broken access control is exclusively an authorization failure.
This vulnerability exists because authorization logic is distributed across codebases, often implemented inconsistently, and rarely tested with the same rigor as functional features. Unlike injection or cryptographic failures, access control bugs do not always produce obvious errors. They silently allow requests that should be denied, returning data or executing actions the requester has no business touching.
The failure is always server-side: the server either does not check authorization at all, checks it incorrectly, or checks it inconsistently across endpoints. This concept is distinct from authentication failures, which involve identity verification problems such as weak passwords or session fixation. A user who bypasses a login screen has exploited an authentication weakness. A user who logs in legitimately and then reads another user's private records has exploited broken access control. The identity verification succeeded; the permission boundary failed.
Broken access control encompasses any condition in which an application grants a user, process, or system access to resources, functions, or data beyond what their assigned role or identity permits. The vulnerability manifests across multiple attack patterns: horizontal privilege escalation where users access peer-level resources they do not own, vertical privilege escalation where users access higher-privilege functions, and direct object manipulation where predictable identifiers allow unauthorized data retrieval.
The core mechanic of broken access control is simple: the application receives a request, confirms the requester is authenticated, and proceeds to fulfill the request without verifying whether that requester is authorized for the specific resource or action involved. The gap between authentication and authorization enforcement is where the exploit lives.
Attack Pattern: Insecure Direct Object References (IDOR)
The most common manifestation involves predictable resource identifiers. An attacker browsing their own account at /api/v1/users/9841/profile immediately sees a numeric identifier. Sequential IDs are trivially enumerable. The attacker modifies the request to /api/v1/users/9840/profile and receives another user's profile data because the server only checked that a valid session token was present, not whether that session's user owns the requested profile.
UUIDs are harder to guess but are often leaked in API responses, email links, or application logs. Administrative endpoints are frequently discoverable through documentation, JavaScript bundles, or directory enumeration. Once an attacker identifies these endpoints, the server's failure to enforce function-level authorization allows direct access.
Concrete Example: Order Management System
A retail application exposes order details at /api/orders/{order_id} with sequential numeric IDs. When a logged-in user requests /api/orders/50120, the application checks the session cookie, confirms authentication, and returns the order details. The developer assumed users would only request their own orders through the UI and implemented no server-side ownership verification.
An attacker scripts requests iterating through order IDs from 1 to 100,000. Each request returns full order details including customer names, shipping addresses, emails, and payment information. The application logs show only authenticated requests. No errors are generated because no application-layer errors occurred. The attacker has scraped every customer's personal data through a series of legitimate API calls.
JWT Role Manipulation
Applications that embed role information in JSON Web Tokens create another attack vector when the server trusts token claims without verification. An attacker captures their token, decodes the payload, and changes "role": "user" to "role": "admin". If the application uses symmetric signing algorithms like HS256 and the attacker can obtain or brute-force the signing secret, they can generate a valid signature for the modified token. The server accepts this token and grants administrative access based on the manipulated role claim.
Missing Function-Level Access Control
Administrative functions are often protected only at the user interface level. Developers hide admin buttons from regular users but fail to enforce authorization on the underlying endpoints. An attacker who discovers admin endpoints through documentation, source code analysis, or directory enumeration can call these functions directly. The server processes admin requests from non-admin users because it never checks whether the authenticated user has administrative privileges.
Metadata and Session Manipulation
Applications frequently store authorization data in cookies, hidden form fields, or URL parameters. An attacker modifies a cookie value from privilege=user to privilege=admin or changes a hidden field from to . If the server trusts this client-side data without validation, it processes the request using the elevated privileges.
File System and Database Access Control Bypasses
Path traversal attacks exploit weak file access controls when applications construct file paths using user input without proper sanitization. An attacker requesting /api/download?file=../../../etc/passwd can access system files if the server does not validate that the requested file is within the authorized directory structure. Similarly, applications that construct database queries using user-provided identifiers without ownership verification allow attackers to access arbitrary database records.
Why Server-Side Enforcement Is Non-Negotiable
Client-side controls including hidden buttons, disabled fields, or omitted menu items are interface decisions, not security controls. Any request that the server accepts and processes is a request the server has implicitly authorized. If an endpoint exists and responds to authenticated requests without checking authorization, the endpoint is vulnerable regardless of whether the user interface exposes it. Attackers interact directly with APIs using tools like curl, Postman, or custom scripts, bypassing the user interface entirely.
Broken access control failures produce immediate and measurable business impact. When authorization boundaries fail, sensitive data flows to unauthorized parties. In healthcare applications, this means exposure of protected health information triggering HIPAA violations. Financial applications expose account balances, transaction histories, and personally identifiable information, triggering regulatory penalties under frameworks like PCI DSS, GDPR, and state privacy laws.
The business consequences extend beyond regulatory penalties. Data breaches damage customer trust and brand reputation. Organizations face class-action lawsuits from customers whose data was exposed. Competitors gain access to proprietary business information. Intellectual property theft through broken access controls can eliminate competitive advantages developed over years.
Real-World Impact: The Parler Data Exfiltration
Following Parler's removal from major app stores in January 2021, researchers began archiving platform content before the service went offline. The platform's API used sequential numeric IDs for posts and media files without enforcing authorization on direct requests. Automated scripts iterated through millions of IDs, downloading posts, videos, and images including GPS metadata embedded in video files.
Over 70 terabytes of content were archived within days through this access control failure. The consequences included exposure of users' location data from videos, personal information tied to posts, and content users believed they had deleted. This was not a sophisticated attack requiring technical expertise. It was systematic enumeration of an unprotected ID space.
Financial and Operational Impact
Beyond regulatory penalties, broken access control creates direct financial exposure. Unauthorized transactions processed through privilege escalation attacks cause immediate monetary loss. Competitors accessing pricing data, customer lists, or strategic plans through horizontal escalation attacks damage business competitiveness. Administrative function abuse allows attackers to modify critical business data, delete records, or reconfigure systems.
Common Misconceptions
Many developers assume web frameworks handle authorization automatically once authentication is configured. Frameworks provide authentication middleware and session management, but authorization decisions about whether specific authenticated identities may perform specific actions on specific resources require explicit application logic. Frameworks provide tools for authorization, but they do not implement business-specific access rules.
Another misconception treats IDOR as only affecting data retrieval. Access control failures affect write operations equally. Attackers who modify other users' profiles, delete content, or submit transactions on behalf of other users have exploited broken access control regardless of whether data was read. Unauthorized write operations often cause greater damage than read operations because they corrupt data integrity and trigger downstream business processes.
Organizations also mistakenly believe that obscuring endpoints provides security. Security through obscurity fails when attackers discover hidden endpoints through documentation, source code analysis, or systematic enumeration. Every endpoint that processes requests must enforce authorization regardless of its visibility.
CDA addresses broken access control through the Sovereign Posture Hygiene (SPH) domain of the Planetary Defense Model. SPH encompasses the continuous, systemic practices that determine how well an organization's security controls maintain their effectiveness over time. Access control is fundamentally a posture element: it cannot be configured once and forgotten but requires ongoing verification, testing, and adaptation as applications evolve.
The Autonomous Posture Command (APC) methodology operationalizes SPH through its core principle: "Your posture adapts. Your hygiene never sleeps." Applied to broken access control, this means authorization coverage receives continuous validation rather than periodic assessment. CDA's approach does not treat authorization testing as a point-in-time penetration testing activity but as a continuous security signal integrated into development and operations workflows.
APC differs from conventional security approaches by making authorization testing operational rather than episodic. Traditional security programs conduct annual penetration tests that may identify IDOR vulnerabilities, produce reports, and track remediation through ticketing systems. APC embeds authorization validation into continuous integration pipelines, running automated tests against every API endpoint with valid but unauthorized session tokens. Any endpoint returning successful responses to unauthorized requests generates immediate alerts and blocks deployment.
Operational Implementation Under APC
CDA recommends centralized policy enforcement points where authorization decisions flow through a single, auditable policy engine rather than distributed controller logic. This architectural approach makes authorization policies inspectable, testable, and modifiable from a central location. Policy engines maintain explicit mappings between roles, resources, and permitted actions, making access control decisions traceable and compliant with audit requirements.
Least-privilege baseline enforcement starts every role with zero permissions, requiring explicit grants for each function. APC includes scheduled reviews of role-permission mappings to identify privilege creep where accounts accumulate permissions over time through role changes that are never reversed. These reviews generate specific remediation actions with assigned owners and completion deadlines.
Authorization regression testing becomes part of the definition of done for new features. Developers cannot merge code that lacks corresponding authorization test coverage. These tests validate not only that authorized users can access appropriate resources but that unauthorized users cannot access resources they do not own, even with valid authentication credentials.
Measurable Security Posture
CDA's differentiation lies in operational specificity and measurable outcomes. Rather than advising organizations to "implement proper authorization," APC defines concrete checkpoints: which endpoints were tested, which user roles were tested against them, what the expected and actual results were, and when tests last executed successfully. Security posture becomes quantifiable through metrics like authorization test coverage percentages, policy enforcement point availability, and privilege review completion rates.
This approach transforms access control from an aspirational security goal into an operational capability with clear success criteria and measurable hygiene indicators.