What is Broken Access Control?
Broken access control happens when an application fails to enforce user permissions properly. Attackers can then act outside their intended privileges, such as viewing another user’s data, changing system settings, or gaining admin-level access.
These vulnerabilities often go unnoticed during normal use because the application appears to work correctly. The vulnerabilities surface only when someone manipulates URLs, modifies request parameters, or sends requests the interface never offered. Attackers use these techniques to bypass access restrictions and reach data or functions that should be off-limits.
Broken access control affects more than web applications. The same vulnerabilities appear in APIs, mobile app backends, cloud services, and AI agents that act on behalf of users.
OWASP A01:2025 – Broken Access Control
Broken Access Control is consistently one of the most exploited vulnerabilities in real-world attacks. In the OWASP Top 10 – 2025, it is ranked as A01:2025 – Broken Access Control, making it the most critical web application security risk.
The 2025 data shows how widespread the problem is:
- Most tested applications are affected: According to OWASP, every application tested showed some form of broken access control. The category had the highest number of occurrences in the contributed data and the second-highest number of related CVEs.
- The largest category: On average, 3.73% of applications tested had one or more of the 40 CWEs mapped to this category. That’s the maximum number of CWEs OWASP allows per category.
- SSRF is now included: Server-Side Request Forgery (SSRF), a separate category in 2021, has been rolled into A01:2025.
Notable CWEs in this category include CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor), CWE-201 (Exposure of Sensitive Information Through Sent Data), CWE-918 (SSRF), and CWE-352 (Cross-Site Request Forgery). The broader parent weakness is CWE-284 (Improper Access Control), and closely related entries include CWE-285 (Improper Authorization), CWE-639 (Authorization Bypass Through User-Controlled Key), CWE-862 (Missing Authorization), and CWE-863 (Incorrect Authorization).
For the complete list, see our guide to the OWASP Top 10 vulnerabilities.
Common Types of Broken Access Control Vulnerabilities
Broken Access Control takes many forms. These are the most common and dangerous patterns:
Vertical Privilege Escalation
Vertical escalation happens when a user with limited rights reaches high-privilege features, such as an admin panel. It usually results from missing role checks on backend endpoints. Hiding admin links in the interface offers no protection. Access must be enforced on the server.
Example: A standard user sends a request directly to /admin/deleteUser and successfully deletes user accounts.
Horizontal Privilege Escalation
Horizontal escalation happens when a user reaches another user’s data at the same privilege level. It usually stems from Insecure Direct Object References (IDOR), where the application grants access to an object based only on user input, such as an ID in the query string. In APIs, the same flaw is called Broken Object Level Authorization (BOLA), the top risk in the OWASP API Security Top 10.
Example: Changing /user/profile?id=102 to /user/profile?id=103 shows another user’s information.
Unprotected or Obscured Endpoints
Developers sometimes hide sensitive endpoints behind obscure URLs, such as /admin-xyz123. Obscurity offers no real protection.
Parameter-Based Role Manipulation
Access should never depend on user-controlled inputs like cookies or query strings. If a role is determined by a parameter (/dashboard?role=admin), attackers can simply modify it to gain access.
Token and Session Manipulation
Some applications trust claims inside a token without verifying them properly. Attackers tamper with JSON Web Tokens (JWTs), reuse expired tokens, or change role claims to raise their privileges. Learn more about JWT token abuse detection.
Misconfigured Platform-Level Rules
Improper server or framework configurations can open doors. For instance, relying on headers like X-Original-URL for path control without proper validation can allow access bypasses through proxy tricks or request smuggling.
Method and Path Bypass
Some apps enforce controls only for certain HTTP methods or exact path formats. Attackers can change method types (e.g., from POST to GET) or alter URL casing (/Admin/DeleteUser vs /admin/deleteuser/) to sidestep checks.
Server-Side Request Forgery (SSRF)
In SSRF, an attacker tricks the server into sending requests to internal systems it can reach but the attacker cannot, such as cloud metadata services or internal admin APIs. The server’s own network access becomes the bypass. Learn more about server-side request forgery.
Chained Escalations
A seemingly minor horizontal escalation can be chained into vertical escalation. For example, compromising a mid-level user’s account via password reset flaws, then using that access to escalate further.
How Broken Access Control Happens
Broken access control often arises from improper enforcement of authorization rules, allowing users to act outside their intended permissions. Here’s a breakdown of how it typically occurs:
1. Over-Reliance on Client-Side Enforcement
Many applications attempt to restrict access by hiding UI elements (like admin links or buttons) or using client-side JavaScript checks. However, this method assumes users won’t manipulate the interface, which is a dangerous assumption.
Attackers can inspect HTML/JavaScript, uncover hidden options, and manually construct requests to access restricted functions. Since enforcement isn’t happening server-side, these client-only controls offer no real protection.
2. Missing or Weak Backend Authorization
Authentication (verifying who a user is) and authorization (verifying what they’re allowed to do) are separate concepts but are often conflated. Many vulnerabilities arise when applications check if a user is logged in but fail to verify if that user has permission to perform a specific action.
For example, an endpoint like /admin/deleteUser might be accessible to any logged-in user if there’s no role-based check on the backend. Attackers can easily exploit this by modifying requests or guessing endpoint paths.
3. Insecure Direct Object References (IDOR) and Parameter Tampering
This occurs when access to internal objects (like user accounts, documents, or order histories) is granted purely based on user-controlled parameters, such as ?userId=102.
If there’s no proper ownership validation, an attacker can change this ID to view or modify another user’s data. Without object-level permission checks, even non-admin users can perform unauthorized actions.
4. Improper Role and Session Management
Applications sometimes fail to properly update or revoke access when a user’s role changes or after they log out. For example:
- A demoted admin may retain elevated privileges due to cached or outdated session tokens.
- Users may still access restricted resources after logging out if sessions aren’t properly invalidated.
- Temporary privileges might not be revoked after use.
Such oversights lead to lingering access beyond what is intended or safe.
5. Misconfigured or Incomplete Access Control Rules
Many frameworks offer built-in access control mechanisms, but improper configuration can leave gaps. Relying on headers like X-Forwarded-For or X-Original-URL for enforcing access without validation can lead to bypasses, especially when proxies are involved. Similarly, trusting IP-based restrictions without proper checks opens the door to spoofing and privilege escalation.
Risks and Impact of Broken Access Control
Unauthorized Data Exposure: When access controls are weak or misconfigured, attackers can easily view, modify, or extract sensitive information. This could include customer data, internal documents, or application source code. Even a simple IDOR flaw can expose large volumes of confidential data, leading to a serious breach.
Privilege Escalation Attacks: A common consequence of broken access control is privilege escalation—where a user gains more access than they should. For instance, a regular user may manipulate requests or exploit insecure endpoints to gain admin-level privileges, allowing them to alter configurations, access sensitive records, or disrupt operations.
Compliance Failures: Broken access control can breach key compliance mandates like PCI DSS Requirement 7, which requires access restricted by business need to know and least privilege; HIPAA’s Access Control Standard (45 CFR §164.312(a)(1)), which requires technical safeguards to prevent unauthorized access to ePHI; and ISO 27001:2022 Annex A controls 5.15 (Access control), 5.18 (Access rights), 8.2 (Privileged access rights), and 8.3 (Information access restriction), which define how access is granted, reviewed, and restricted. Violations can expose sensitive data, lead to non-compliance penalties, and invite regulatory action. Ensuring proper access enforcement is critical for staying audit-ready and maintaining trust.
Business Disruption: Attackers with unauthorized access can manipulate business logic, delete critical data, or disable systems. These disruptions can lead to downtime, service outages, and loss of productivity, impacting both operations and customer experience.
Legal and Financial Consequences: Access control failures often trigger financial loss due to incident response, forensics, and recovery costs. In regulated industries, it could also lead to lawsuits and penalties. Additionally, if customer data is exposed, the resulting reputational damage can lead to lost business and long-term brand erosion.
How to Detect Broken Access Control
Detecting broken access control involves both proactive testing and continuous monitoring. Here are key ways to uncover these vulnerabilities:
AI-assisted penetration testing: AI-assisted penetration testing, such as the one in Indusface WAS, maps the application’s endpoints, user roles, and multi-step workflows, then tests hypotheses about where authorization could break. It simulates real attacks, such as changing user IDs in URLs, calling admin functions as a standard user, or skipping steps in a workflow. Each confirmed flaw is retested across every endpoint that shares the same logic, so one IDOR finding shows every affected endpoint. Certified pentesters validate high-impact findings, covering both vertical and horizontal access issues.
Code Reviews: Reviewing backend code helps ensure that access controls are enforced on the server. Look for missing role checks, hardcoded roles, or access based solely on user-supplied input.
Security Misconfiguration Testing: Evaluate application and server configuration to detect exposed admin endpoints, improperly set permissions, or insecure URL-based access control mechanisms.
Role-switching tests: These tests help ensure that applications correctly update and enforce permissions when a user’s role changes. They verify that downgraded users immediately lose access to privileged actions and can no longer perform functions tied to their previous role. These tests also check whether the system invalidates or refreshes sessions after a role change to prevent privilege retention.
Logs and analytics: Uncover valuable clues including repeated access attempts to restricted endpoints, unusual access patterns, or unexpected HTTP status codes (such as frequent 403s followed by 200s) which may indicate access misuse.
How to Prevent Broken Access Control Vulnerabilities
Preventing broken access control takes secure development practices, rigorous testing, and continuous monitoring. These are the key strategies:
1. Enforce Server-Side Authorization
Client-side restrictions, such as hidden buttons or disabled inputs, are easy to bypass. Every access control decision must happen on the server, where users can’t manipulate the logic.
Validate every request on the backend for the user’s role, ownership of the resource, and specific permissions before granting access. For example, even if a user can see a “Delete” button, the server should block the request if that user lacks admin right
2. Use Role-Based or Attribute-Based Access Control
Centralize access rules with a proven model:
- RBAC (Role-Based Access Control): Assign roles, such as admin, editor, or viewer, each with specific permissions.
- ABAC (Attribute-Based Access Control): Grant access based on user attributes, resource types, and conditions, such as location or time of access.
Most frameworks include tools for this. Laravel provides Gates and Policies. Rails applications commonly use Pundit or CanCanCan. Spring Security supports method-level checks with @PreAuthorize, and ASP.NET Core offers policy-based authorization. Using these consistently keeps access logic in one place and makes missing checks easier to spot.
3. Deny by Default
Follow the principle of least privilege: users should only have access to what’s necessary.
By default, assume users should not have access unless explicitly allowed. This prevents accidental exposure of sensitive features or data.
For example, avoid using wildcard permissions like * in APIs or roles that inherit unnecessary privileges.
4. Secure APIs and Endpoints
APIs are prime targets for Broken Access Control. Secure them by:
- Requiring proper authentication and authorization on every endpoint.
- Avoiding predictable object IDs (use UUIDs or indirect references instead).
- Validating access for every operation (GET, POST, PUT, DELETE). Don’t assume prior requests prove future access.
- Also, use OpenAPI specifications to define and enforce expected request structures and roles.
5. Manage Sessions and Tokens Securely
Invalidate sessions on the server after logout and after any role change. Keep JWTs and other stateless tokens short-lived, and verify their signatures and claims on every request.
6. Implement Access Control at the Code and Infrastructure Level
Use framework features (like middleware or decorators) to enforce access checks at a central layer in your codebase.
Set access rules at the system layer using tools such as API gateways, reverse proxies, or web application firewalls (WAFs) to restrict traffic.
7. Log and Alert on Access Control Failures
Log every access control failure and alert on repeated failures from the same user or source. Fast alerts help teams catch attackers while they are still probing.
8. . Deploy a Web Application Firewall
Web Application Firewall (WAF) adds an important layer of defense. It detects and blocks common exploit patterns such as path traversal, predictable endpoint access, and unauthorized role manipulation. By using attack signatures, anomaly detection, and custom access rules, a WAF can prevent attempts to bypass authentication or access restricted resources.
Code fixes for access control vulnerabilities often take weeks to reach production. Virtual patching at the WAF blocks exploitation of a known flaw immediately, while developers build and release the permanent fix.
9. Test Continuously
Access control breaks easily when new features, endpoints, and roles are added. Test authorization on every release, and include role-switching and object-ownership tests in your automated test suites.
Broken Access Control Prevention Checklist
- Authorization is enforced on the server for every request
- Every endpoint checks the user’s role and ownership of the requested object
- Access is denied by default, with no wildcard permissions
- Object IDs are non-sequential or indirect
- Sessions are invalidated on logout and role change
- Tokens are short-lived with verified signatures and claims
- Headers like X-Original-URL are never trusted for access decisions
- CORS policies allow only trusted origins
- AI agents act with the requesting user’s permissions, never broader ones
- Access control failures are logged and alerted on
- Authorization tests run on every release