Access Control Bypass
A vulnerability that allows an attacker to access resources, data, or functionality they are not authorized to use, circumventing the system's authorization enforcement.
Access control bypass is classified under CWE-284 (Improper Access Control) and its sub-weaknesses (CWE-285, CWE-639, CWE-548). It became the #1 vulnerability in the OWASP Top 10 2021, moving up from #5 in 2017, reflecting both its prevalence in code review findings and the severity of its real-world impact — including data breaches at major platforms.
The vulnerability differs fundamentally from authentication bypass: authentication answers 'who are you?', while authorization (access control) answers 'what are you allowed to do?'. A bypassed access control system may serve a fully authenticated attacker.
Common root causes include:
- Missing function-level authorization checks (checking auth in the UI but not the API endpoint)
- Relying on client-supplied data for authorization decisions (e.g., a hidden form field with role=admin)
- Insufficient object-level checks (IDOR)
- Overly permissive CORS policies enabling cross-origin API calls
- JWT or session token manipulation (modifying sub, role, or scope claims without signature validation)
Real-world impact: Facebook's 2021 data leak of 533 million records was partly attributed to an IDOR vulnerability in a phone number lookup feature. Equifax 2017 breach involved a path traversal component. IDOR vulnerabilities accounted for a significant portion of HackerOne bug bounty payouts in 2022-2024.
graph LR
Center["Access Control Bypass"]:::main
Pre_authentication["authentication"]:::pre --> Center
click Pre_authentication "/terms/authentication"
Rel_zero_trust_security["zero-trust-security"]:::related -.-> Center
click Rel_zero_trust_security "/terms/zero-trust-security"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧒 Explain Like I'm 5
Imagine a library where you need a special card to enter the 'staff only' room. [Access control](/en/terms/access-control) bypass is like finding a window that staff forgot to lock, or finding a trick where if you ask for the staff room in a slightly weird way, the guard just lets you in without checking your card. You're already in the library (you're logged in), but you're getting into rooms you're not supposed to.
🤓 Expert Deep Dive
Access control bypass encompasses several distinct attack patterns, each targeting different enforcement points in an application's authorization layer:
1. Insecure Direct Object Reference (IDOR)
The most common subtype. An attacker manipulates a reference (URL parameter, API body field, cookie value) that directly maps to a server-side object. Example: changing GET /api/invoices/1234 to GET /api/invoices/1235 to access another user's invoice. The root cause is missing object-level authorization checks — the server validates the user is authenticated but not whether they own the specific resource.
2. Path Traversal (Directory Traversal)
Attackers inject ../ sequences into file path parameters to escape the intended directory scope. Example: GET /files?name=../../../../etc/passwd. Mitigated by canonicalizing paths before access checks and using allow-lists.
3. Privilege Escalation (Vertical Access Control Bypass)
A lower-privileged user gains access to higher-privileged functions — e.g., a regular user accessing admin endpoints by modifying a role=admin parameter or JWT claim.
4. Broken Object Property Level Authorization (BOPLA / Mass Assignment)
Attackers supply unexpected fields in API requests that modify privileged object properties. A PATCH /users/me request including {"isAdmin": true} that the server blindly applies.
5. Forced Browsing
Directly accessing URLs or API endpoints that are not linked in the UI but lack server-side authorization checks (security by obscurity).
Enforcement Models:
- DAC (Discretionary Access Control): Resource owners set permissions.
- MAC (Mandatory Access Control): System-enforced labels (SELinux, MLS).
- RBAC (Role-Based Access Control): Permissions assigned to roles.
- ABAC (Attribute-Based Access Control): Policy engine evaluates attributes of user, resource, and environment — the most flexible and complex model (NIST SP 800-162).
Mitigation:
- Deny by default: reject unless explicitly permitted.
- Enforce authorization server-side on every request — never trust client-supplied role/ID data.
- Use UUIDs instead of sequential IDs to reduce IDOR discoverability.
- Implement automated integration tests that verify unauthorized access returns 403, not 200.
- Log and alert on access control failures.
❓ Frequently Asked Questions
What is the difference between access control bypass and authentication bypass?
Authentication bypass defeats identity verification (you appear as someone you're not). Access control bypass assumes you may be legitimately authenticated but exploits flaws in permission enforcement — you access resources your account is not authorized to use.
Why is broken access control ranked #1 in OWASP Top 10 2021?
It was found in 94% of applications tested during the OWASP data collection period, with 318,000+ CVEs mapping to this category. It moved from #5 (2017) to #1 (2021) due to its prevalence in modern API-driven architectures where authorization checks are frequently incomplete.
How do I test for IDOR vulnerabilities?
Create two test accounts. Perform actions as Account A and capture the resource IDs (invoice IDs, user IDs, document IDs) in the request. Then replay those requests authenticated as Account B. If Account B can access Account A's resources, IDOR exists.