Broken Access Control

Broken Access Control is the most prevalent and dangerous category of web application vulnerabilities, holding the #1 position in the OWASP Top 10 since 2021. It occurs when an application fails to properly enforce restrictions on what authenticated users are allowed to do. When access control mechanisms are missing or improperly implemented, attackers can act outside their intended permissions, accessing other users' data, modifying records they shouldn't touch, or performing administrative functions without authorization.

This vulnerability class encompasses a wide range of specific flaws including Insecure Direct Object References (IDOR), missing function-level access control, privilege escalation, metadata manipulation (such as tampering with JWTs or cookies), CORS misconfiguration, and path traversal. The common thread is that the application trusts the user to stay within their intended boundaries rather than enforcing those boundaries on the server side.

Broken Access Control is particularly dangerous because it directly undermines the confidentiality and integrity of application data. Unlike vulnerabilities that require chaining or complex exploitation, a single missing authorization check can immediately expose sensitive data or allow unauthorized actions. Common manifestations include:

• Horizontal privilege escalation: Accessing another user's resources by modifying an identifier (e.g., changing /api/users/123/profile to /api/users/456/profile)
• Vertical privilege escalation: Performing actions reserved for higher-privileged roles (e.g., a regular user accessing admin endpoints)
• Missing access control on API endpoints that the UI hides but the server still exposes
• Bypassing access control checks through parameter tampering, forced browsing, or modifying API requests

Attackers exploit Broken Access Control by manipulating the requests sent to the server, bypassing client-side restrictions that are trivially circumvented. The most common technique is Insecure Direct Object Reference (IDOR) manipulation, where the attacker modifies identifiers in API calls to access resources belonging to other users or organizations. For example, an attacker might intercept a request like:

GET /api/v1/invoices/INV-2024-0847 HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

And simply change the invoice ID to enumerate other invoices: GET /api/v1/invoices/INV-2024-0001. If the server returns the invoice without verifying that the authenticated user has permission to view it, the access control is broken. Attackers often automate this enumeration using Burp Suite Intruder or custom scripts to harvest large volumes of data.

Another common exploitation vector involves forced browsing to administrative or restricted endpoints. Many applications rely on the UI to hide links to admin pages, but the underlying API endpoints remain accessible. An attacker can discover these endpoints through JavaScript source analysis, API documentation leaks, or predictable URL patterns like /admin/users, /api/admin/settings, or /internal/debug. Privilege escalation attacks may also exploit parameter tampering, such as modifying a role field in a request body:

POST /api/users/update
{"userId": "current-user-id", "role": "admin", "email": "attacker@evil.com"}

More sophisticated attacks target the access control logic itself, exploiting race conditions in permission checks, abusing multi-step workflows where authorization is only checked on the first step, or leveraging CORS misconfigurations to make cross-origin requests that the server trusts. JWT manipulation is another vector: if the server doesn't properly validate token signatures, an attacker can modify claims like "role": "admin" or "tenant_id": "victim-org" to escalate privileges.

• Unauthorized access to sensitive personal data, financial records, healthcare information, or proprietary business data, potentially affecting thousands or millions of users
• Complete account takeover by modifying other users' credentials, email addresses, or authentication tokens
• Regulatory and compliance violations including GDPR, HIPAA, PCI DSS, and SOX, resulting in fines that can reach millions of dollars
• Data manipulation or destruction where attackers modify or delete records belonging to other users, organizations, or tenants
• Privilege escalation to administrative accounts, enabling attackers to control the entire application, create backdoor accounts, or exfiltrate all data
• Multi-tenant data breaches in SaaS applications where broken tenant isolation exposes one organization's data to another
• Reputational damage and loss of customer trust, particularly in B2B environments where security is a key purchasing criterion
• Legal liability from class-action lawsuits and breach notification requirements across multiple jurisdictions

1. Implement server-side access control checks on every request. Never rely on client-side UI restrictions or hidden fields. Every API endpoint and controller action must verify that the authenticated user has the specific permission to perform the requested operation on the requested resource.
2. Adopt a deny-by-default access control model. All requests should be denied unless a specific permission grant exists. Use middleware or interceptors to enforce this at the framework level so individual developers cannot accidentally skip authorization checks.
3. Use indirect object references or enforce ownership checks on all data access. Instead of exposing sequential database IDs, use UUIDs or mapped references. Always include a WHERE clause that scopes queries to the current user's or tenant's data (e.g., WHERE organization_id = :currentOrgId AND id = :requestedId).
4. Implement Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC) with a centralized policy engine. Define permissions in a single location and enforce them consistently across the application. Libraries like CASL (JavaScript), Casbin, or OPA (Open Policy Agent) provide robust policy frameworks.
5. Log and monitor all access control failures. Alert on anomalous patterns such as a single user generating many 403 responses, rapid sequential ID enumeration, or access attempts across tenant boundaries. Feed these logs into your SIEM for correlation.
6. Disable directory listing on web servers and ensure that file metadata, backup files, and source control artifacts (e.g., .git, .env) are not accessible. Configure proper CORS policies that restrict origins to known, trusted domains.
7. Invalidate session tokens and JWTs upon logout, password change, and role modification. Implement token expiration and rotation policies. For stateless JWTs, maintain a server-side revocation list or use short-lived tokens with refresh token rotation.
8. Conduct regular access control audits and automated testing. Include IDOR testing, forced browsing, and privilege escalation test cases in your CI/CD pipeline. Use tools like Semgrep or custom linting rules to detect missing authorization middleware on new endpoints.

Testing for Broken Access Control requires a methodical approach that goes beyond automated scanning. Start by mapping all application endpoints and their expected access control rules. Create a permission matrix that defines which roles can perform which actions on which resources. Then systematically test each cell in that matrix by making requests with different user contexts.

Use Burp Suite Professional as your primary tool for access control testing. The Autorize extension is invaluable: it automatically replays every request made by a high-privileged user with a low-privileged user's session token, flagging cases where the response is identical (indicating missing access control). Configure Autorize with at least two user sessions: one admin and one regular user. For multi-tenant applications, add a session from a different tenant. Manually test IDOR vulnerabilities by intercepting requests in Burp Proxy, identifying resource identifiers (IDs, UUIDs, slugs), and substituting them with identifiers belonging to other users or tenants. Use Burp Intruder to enumerate sequential IDs and compare response lengths and status codes.

OWASP ZAP's Access Control Testing add-on provides similar automated testing capabilities. For API-heavy applications, import the OpenAPI/Swagger specification into Postman or Burp and systematically test each endpoint with different authentication contexts. Write custom scripts using Python with the requests library to automate complex multi-step authorization bypass scenarios. Test for JWT manipulation using tools like jwt_tool by Auth0, attempting algorithm confusion attacks (changing RS256 to HS256), signature stripping (setting alg to "none"), and claim modification. Check for path traversal bypasses like /admin/../admin/users, HTTP method tampering (changing GET to POST or vice versa), and HTTP header injection (X-Original-URL, X-Forwarded-For) that may bypass access controls implemented at the reverse proxy level.