What is a broken access control vulnerability?
Access control—also known as authorization—determines what authenticated users are allowed to do within a web application. While authentication verifies identity, access control governs permissions. Despite its conceptual simplicity, implementing effective access control is complex and frequently flawed.
According to the OWASP Top 10 for 2021, broken access control ranks as the most critical web application security risk, with 94% of tested applications exhibiting some form of access control weakness.
Common issues include violations of the principle of least privilege and the failure to enforce deny-by-default policies. These gaps can lead to unauthorized data access, content modification, or execution of functions beyond a user’s intended permissions.
Types of broken access control attacks
Broken access control can take many forms depending on how permissions are implemented—and where they are overlooked. Below are several common types of access control vulnerabilities that security teams frequently encounter. Other examples include forced browsing, insecure default permissions, and reliance on client-side access check enforcement.
Exploiting endpoints
This involves directly accessing application functions or APIs, bypassing the intended user interface or role restrictions. Attackers may invoke hidden or undocumented endpoints that are assumed to be protected by session state or client logic, but are actually accessible without proper validation.
Example: An attacker calls an /admin/deleteUser API while logged in as a regular user because the server fails to verify their role.
URL manipulation
This method targets predictable URL parameters to access unauthorized resources. By altering query strings or path segments, attackers can retrieve or modify data associated with other users, assuming the server doesn’t enforce proper checks.
Example: A user accesses /profile?user_id=101 and changes it to /profile?user_id=102 to view another user’s profile.
Indirect object references (IDOR)
IDOR flaws occur when internal objects (like database records or files) are referenced via user-supplied input, and the application does not verify whether the requester is authorized to access the object. Unlike URL manipulation, IDOR may occur in headers, request bodies, or cookies.
Example: A mobile app sends {"invoice_id": "30925"}. Modifying the ID exposes another user’s invoice because the server doesn’t check ownership.
Elevating user privileges
Privilege escalation occurs when users gain access to higher-level functionality or data due to logic flaws or weak role enforcement. This often involves manipulating session tokens, roles, or permissions assumed to be secure on the client side.
Example: A user modifies their role=user session token to role=admin and gains administrative access because the server does not revalidate it.
Broken access control attack examples
Given the widespread nature of these issues, it’s no surprise that several high-profile breaches have been linked to broken access control. The following incidents illustrate how impactful these vulnerabilities can be.
Snowflake customer data breach
In June 2024, attackers accessed sensitive customer data from Snowflake environments by using stolen credentials without multi-factor authentication (MFA). Though the Snowflake platform itself was not directly at fault, weak access controls and overly permissive configurations allowed unauthorized logins into customer-managed environments.
This breach underscores the importance of enforcing MFA, role restrictions, and least-privilege principles—even on well-secured platforms. (Source: TechCrunch)
Kia web portal vulnerability
Also in June 2024, researchers uncovered a critical access control flaw in Kia and Hyundai’s connected vehicle APIs. By supplying only a license plate number or VIN, attackers could access APIs meant for authenticated users, enabling remote control of vehicle functions.
The vulnerability stemmed from poor authentication and missing authorization checks. It highlights how access control failures in API-driven environments can pose real-world safety risks. (Source: Wired)
MOVEit transfer data breach
In 2023, a zero-day vulnerability in MOVEit Transfer (CVE-2023-34362) was exploited by the Cl0p ransomware group. The underlying flaw was SQL injection, but it was the lack of authentication on a critical endpoint that allowed attackers to reach and exploit it.
This combination of a technical vulnerability and broken access control enabled the compromise of over 2,000 organizations and the data of more than 62 million individuals. (Source: TechCrunch)
How to prevent broken access control
While not exhaustive, the following practices are key strategies for reducing access control risk and improving application security posture.
Implementing the principle of least privilege
Grant users and systems only the access needed to perform their tasks—nothing more. This limits exposure and reduces the potential impact of a compromised account.
Access controls should be enforced in server-side logic or trusted serverless APIs. Use a deny-by-default policy, and implement access checks consistently across the application.
Secure session management and authentication controls
Use stateful session identifiers that expire on logout. Shorten the lifespan of stateless tokens like JWTs, and implement revocation mechanisms per OAuth standards.
Avoid embedding roles in client-side code or hardcoding them into applications. Instead, use attribute-based controls for greater flexibility and security.
Regular access control audits and reviews
Routinely test access control mechanisms during development and production. Conduct code reviews and penetration testing to detect gaps in logic or enforcement.
Disable unnecessary directory listings, protect sensitive files, and alert on repeated access control failures.
Proper error handling and logging
Suppress detailed error messages that may reveal access logic. Log failed access attempts and monitor for suspicious activity. Implement rate limiting to defend against brute-force probes.
Final thoughts on broken access control
Broken access control remains one of the most dangerous and prevalent vulnerabilities in modern applications. From missing role checks to exposed admin functions, these flaws often lead directly to serious breaches.
As seen in the real-world examples above, the impact of broken access control can be operational, financial, and reputational. Securing applications requires continuous attention to access control design, implementation, and validation.
This is where a DAST-first approach, as used in the Invicti AppSec platform, proves critical. Dynamic application security testing (DAST) scans live applications as an attacker would—identifying exposed endpoints, missing checks, and logic flaws in real time. Invicti’s proof-based scanning validates exploitability, helping teams prioritize and fix issues that matter.
Access control is not optional or static—it’s a foundational layer that demands consistent scrutiny. Getting it right is essential, and DAST helps you focus on what attackers can exploit.
FAQ
Broken access control is the failure to enforce rules that limit what authenticated users can do. While authentication confirms identity, access control governs permissions. When misconfigured, it can allow attackers to view, change, or control data and functions beyond their intended scope.
The three core models are Discretionary Access Control (DAC), where resource owners set permissions; Mandatory Access Control (MAC), which uses security classifications; and Role-Based Access Control (RBAC), which assigns permissions based on user roles. Variants like Attribute-Based Access Control (ABAC) offer additional flexibility in modern systems.
Broken access control occurs when users can access data or functionality they shouldn’t. This includes failures such as missing role checks, insecure endpoints, and exploitable object references. OWASP identifies it as the most critical and common application vulnerability.
Typical issues include overly broad permissions, lack of deny-by-default logic, IDOR flaws, and access logic scattered across the codebase. These problems are often rooted in inconsistent design, client-side enforcement, or a lack of testing and review. Even minor oversights can lead to large-scale compromise.
Get the latest content on web security
in your inbox each week.
