Broken access control happens when an application fails to enforce authorization—who is allowed to do what—letting attackers view or modify data and use functions they shouldn’t. It’s ranked as the top threat (A01:2021) in the Open Web Application Security Project (OWASP) Top 10 and remains both prevalent and high-impact: OWASP observed 94% of tested apps with some form of access control weakness, with 318k+ occurrences across 34 mapped CWEs—more than any other category. With the OWASP Top 10 2025 update imminent, now’s the time to double-check authorization in both web and API flows.
What is Broken Access Control and Why it Matters

Access control (authorization) decides which authenticated users (or services) can access which resources and actions. Broken access control means those rules aren’t enforced consistently—so a user can read another user’s data, call an admin-only function, or hop tenants.
AuthN vs AuthZ, in one line: authentication is who you are; authorization is what you’re allowed to do after login. BAC is an authorization failure.
Broken access control is a critical security vulnerability that occurs when an application fails to adequately enforce authorization and authentication mechanisms. Essentially, it allows individuals to access resources, data, or functionalities that they are not entitled to. This breakdown in security can have far-reaching consequences for both businesses and individuals.
Imagine a scenario where unauthorized users can access sensitive customer information, modify financial records, or even escalate their privileges to become administrators. The potential impacts of such a breach are severe:
- Financial loss: Unauthorized transactions, fraud, and data theft can result in significant financial damages.
- Reputation damage: A data breach can erode customer trust, leading to loss of business and negative publicity.
- Legal repercussions: Non-compliance with data protection regulations can result in hefty fines and legal liabilities.
- Competitive disadvantage: Sensitive business information falling into the wrong hands can compromise strategic advantages.
Understanding the nature of broken access control vulnerabilities and implementing robust countermeasures is essential to protect your organization's assets and maintain customer confidence.
Broken Access Control in OWASP: A Critical Threat

As we've established, broken access control is a severe security risk with potentially catastrophic consequences. Recognizing the criticality of this issue, the Open Web Application Security Project (OWASP) has consistently ranked it as a top-tier vulnerability in its annual owasp Top 10 list. OWASP is a non-profit foundation dedicated to improving software security worldwide, providing invaluable resources and guidance for developers and security professionals.
By placing broken access control at the forefront of its research and advocacy efforts, OWASP underscores the pervasive nature of this threat and the urgent need for effective mitigation strategies. Understanding the specific types of broken access control vulnerabilities identified by OWASP is essential for developing a comprehensive defense.
In 2021, Broken Access Control jumped from #5 (2017) to #1, driven by its ubiquity and impact. The contributed dataset shows 94% of applications with some BAC finding, 3.81% average incidence rate, >318k occurrences, and 34 CWEs mapped—the most of any category. Expect BAC to remain a focal point as OWASP Top 10 2025 lands, given the continued rise of API-centric apps and multi-tenant SaaS.
Common Broken Access Control Attack Techniques

Broken access control vulnerabilities can be exploited through various methods. Understanding these tactics is crucial for effective prevention. Attackers constantly develop new techniques to bypass access controls, so staying informed about common attack vectors is essential for robust security. Here are some of the most prevalent broken access control attack techniques:
- Horizontal Privilege Escalation
Horizontal privilege escalation exploits vulnerabilities in session management or authorization checks to elevate an attacker's privileges to the same level as another user. For example, an attacker might steal a legitimate user's session ID and use it to impersonate that user and gain access to their resources. (Often rooted in IDOR) - Vertical Privilege Escalation
Vertical privilege escalation exploits vulnerabilities in authorization controls to gain access to resources or functionalities that are typically reserved for users with higher privileges. For instance, an attacker might find a way to bypass a check that restricts access to administrative features and gain unauthorized administrative access. - Parameter Tampering
Attackers can manipulate URL parameters or form field values to trick the application into giving them unauthorized access. For instance, an e-commerce application might use a user ID parameter in the URL to display a specific user's shopping cart. By modifying this parameter, an attacker could potentially view another user's cart contents. - IDOR (Insecure Direct Object Reference):
the app uses user-controlled identifiers to fetch objects without verifying ownership (classic parameter tampering across users or tenants). - Data Exposure Through Public URLs
Sensitive data can be inadvertently exposed through publicly accessible URLs due to misconfigurations or application logic errors. These vulnerabilities can lead to severe data breaches if not addressed promptly. - API Abuse
Web APIs, if not properly secured, can become a prime target for attackers. By manipulating API endpoints or input parameters, malicious actors can gain unauthorized access to data, perform unintended actions, or even launch denial-of-service (DoS) attacks. - API authorization gaps
endpoints accept client-supplied identifiers/claims without verifying object-level access (BOLA). These must be checked server-side in every function that touches user-provided IDs
Recent Real-world examples
Optus (2022): a dormant API and an access-control coding error
In September 2022, Optus disclosed a breach that exposed the personal data of roughly 10 million current and former customers. In subsequent legal filings, Australia’s communications regulator (ACMA) alleged that a coding error in access control left an API open to abuse for years, allowing unauthenticated requests to reach customer records. Reports on the filings note that the flaw went undetected for a long period prior to the incident, underscoring how a single missed server-side check on an internet-facing endpoint can negate every other control around it.
For engineering teams, the takeaway is painfully clear: treat all external endpoints as hostile; enforce deny-by-default policies on the server; and continuously inventory, test, and retire “dormant” apps and APIs so old access-control mistakes don’t become tomorrow’s breach headline. (Analyses of the case also highlight the risk of legacy endpoints drifting out of policy as systems evolve.)
Source: CSO Online, iTnews, Cyber Daily, Security Scorecard
Kia (2024): from a license plate to remote vehicle control
In June 2024, independent researchers demonstrated a chained flaw in Kia’s web portal that let them take over connected-car functions using only a license plate number. By exploiting weak ownership verification and authorization checks, they could reassign control from a legitimate owner’s app to their own device—enabling tracking, unlocking, and even remote start—before Kia patched the issues after coordinated disclosure. The episode is a textbook example of broken access control in APIs: insufficient, inconsistent server-side authorization across critical actions.
The lesson for high-risk operations (money movement, admin tools, vehicle control) is to require strong, centralized server-side authorization for every action, bind operations to the authenticated principal (not user-supplied identifiers), and add step-up authentication for sensitive commands. When clients can influence which account or object an API operates on (e.g., by passing a license plate or ID), every handler must perform object-level authorization before doing anything else.
Source: samcurry.net, WIRED
What is Broken Access Control Vulnerability

Broken access control encompasses a wide range of vulnerabilities that arise when applications fail to properly enforce authorization and authentication mechanisms. These vulnerabilities can manifest in various forms, each with its own characteristics and potential impact. Understanding these types is crucial for effective prevention and mitigation strategies. Here are some of the most common broken access control vulnerabilities:
Types of Broken Access Control Vulnerabilities
- Insecure Direct Object References (IDOR)
IDOR occurs when an application exposes unique identifiers for resources directly in the URL or other accessible parameters. This allows attackers to manipulate these identifiers to access unauthorized data or perform actions. For example, if an e-commerce site uses order IDs directly in URLs without proper authorization checks, an attacker could potentially view or modify other users' orders. - Violation of the Principle of Least Privilege
This vulnerability arises when users are granted excessive permissions, exceeding the minimum necessary for their roles. By assigning broader privileges than required, organizations increase the attack surface, making it easier for malicious actors to exploit vulnerabilities and escalate their access. For instance, if a customer support representative has administrative privileges, they could potentially misuse their access to modify sensitive data or perform unauthorized actions. - Access Control Checks Bypass
Attackers can often circumvent access controls by exploiting vulnerabilities like SQL injection or cross-site scripting (XSS). By injecting malicious code, they can manipulate application logic to bypass authorization checks and gain unauthorized access. For instance, an attacker might inject malicious code into a web form to elevate their privileges or access restricted data. - Session Management Flaws
Improper session management can lead to session hijacking, where attackers steal valid session tokens to impersonate authenticated users. This allows them to access the victim's account and perform actions on their behalf. Weak session management practices, such as using predictable session IDs or storing sensitive information in session cookies, increase the risk of unauthorized access. - Elevation of Privilege
Elevation of privilege occurs when an attacker with lower-level privileges can escalate their access to perform actions normally restricted to higher-privileged users. This can involve exploiting vulnerabilities in the application's logic or infrastructure to bypass authorization controls. For example, a standard user might find a way to exploit a vulnerability to gain administrative access.
A practical checklist to Prevent Broken Access Control Vulnerabilities

Broken access control vulnerabilities pose a significant threat to web applications, potentially exposing sensitive data and compromising user privacy. To effectively safeguard your application, a comprehensive security strategy that addresses access control at multiple levels is essential. Here are a few checklist items to prevent broken access control vulnerabilities and create a more secure environment for your users and data.
1. Deny by default & enforce server-side
Gate every protected resource/action on the server. Centralize policy enforcement rather than scattering checks in controllers/UI. Don’t rely on client-side controls or obscurity.
2. Least privilege with RBAC/ABAC
Grant only the minimum permissions needed. Use role/attribute-based policies, review entitlements regularly, and guard “break-glass” paths.
3. Session & token hygiene (step-up where needed)
Short-lived tokens; rotation/invalidation on logout; secure cookies; bind sessions; require MFA or step-up for sensitive operations.
4. Never trust user-controlled claims/IDs
Treat user_id
, org_id
, or object IDs as untrusted. Re-look up the subject from the authenticated context and check ownership/tenancy before every read/write. For APIs, apply object-level authorization in every function that uses a user-supplied identifier.
5. Logging, rate limiting, and anomaly alerts
Log denied and attempted access to sensitive routes; alert on bursts, cross-tenant access, unusual role use. Use rate limits to curb brute-force/enumeration of object IDs.
6. Test authorization explicitly
Unit/contract tests for permission boundaries; negative tests (cross-user/tenant); integration tests around critical flows; periodic authZ-focused pentests.
By combining these approaches, you can create a multi-layered defense against broken access control vulnerabilities. Regular code reviews can help identify potential vulnerabilities early in the development lifecycle, before they are introduced into production. Additionally, staying up-to-date with the latest security threats and patching vulnerabilities promptly is essential for maintaining a secure environment. By implementing these strategies, you can significantly reduce the risk of unauthorized access to your application and data.
A Common Misconception: The Least Effective Security Mechanism

Before we conclude, let's address a common misconception about web application security. A frequent question is: "Which security mechanism is the least effective against common web application attacks?"
While all security measures are essential components of a robust defense strategy, relying solely on a single mechanism is generally insufficient. However, one practice that often proves to be less effective on its own is client-side validation.
Client-side validation involves implementing checks and validations within a web browser's JavaScript code. This can include techniques like ensuring that form fields are filled out correctly or verifying the format of user input. While client-side validation can provide an initial layer of protection by catching errors and preventing invalid data from being submitted, it should never be the sole defense against attacks. Malicious users can easily bypass client-side checks by manipulating the browser's environment or using specialized tools to modify requests directly. For instance, a skilled attacker could modify the JavaScript code responsible for client-side validation, effectively disabling its security measures. Additionally, client-side validation is entirely dependent on the functionality of the user's browser. If a user has a disabled scripting environment or an outdated browser with known vulnerabilities, client-side validation becomes even less reliable.
Therefore, it's crucial to always prioritize server-side validation and other security measures to ensure comprehensive protection. Server-side validation, performed on the web server after receiving user input, offers a more robust layer of defense. By implementing server-side validation, you can ensure that even if a client-side check is bypassed, the application itself can still verify the legitimacy of user input and prevent unauthorized access or malicious code injection.
FAQs
Is Broken Access Control the same as Broken Authentication?
No. Authentication proves identity. Authorization decides which identities can access what. BAC is an authorization failure.
What’s least effective against BAC?
Client-side checks alone. Assume the client is hostile. Always enforce authorization checks server-side with deny-by-default policies.
How do we catch BAC earlier in the SDLC?
Model access rules; write unit/contract tests per resource/action; add negative tests for cross-user/tenant; make authZ checks part of your CI “quality bar,” and schedule periodic authZ-focused pentests.
Protect Your Application with Expert Guidance
Protecting your application from broken access control vulnerabilities is essential for maintaining user trust and safeguarding sensitive data. By implementing robust security practices, you can significantly reduce the risk of unauthorized access and data breaches.
If you have concerns about your application's security or need assistance in preventing broken access control, don't hesitate to reach out to our security experts. We offer comprehensive security assessments and can help you develop a tailored protection strategy. Let us help you build a resilient application that can withstand modern threats.