Broken Access Control — OWASP Top 10 A01 (2026)
Written by the Rafter Team
· Updated
Estimated reading time: ~12 minutes
Broken Access Control is the OWASP Top 10 category (A01) for authorization failures—cases where an application correctly verifies who a user is but never checks what that user is allowed to do, letting them read, modify, or delete data outside their own permissions. It has held the #1 spot since the 2021 edition and stays #1 in the current OWASP Top 10:2025, and OWASP's own contributed data explains why: 100% of applications tested showed some form of broken access control, and the category logged more than 1.8 million occurrences of related CWEs, the highest of any category. The 2025 edition also folded in Server-Side Request Forgery (SSRF), since a forged server-side request is the same underlying failure—a missing check on what a request is allowed to do—one layer down the stack.
Related: the full OWASP Top 10 2026 ranking
Hook
In 2023, a fintech startup accidentally left an endpoint unprotected. By simply changing a user_id in the URL, attackers could view other customers' financial data. No SQL injection, no malware, just a basic access control failure.
This type of bug — Broken Access Control — is consistently ranked as the #1 risk on the OWASP Top 10 because it's so common and devastating.
In this post, we'll break down what Broken Access Control is, show real-world examples, and give you the tools and practices to prevent it.
The Problem
In 2023, a fintech startup accidentally left an endpoint unprotected. By simply changing a user_id in the URL, attackers could view other customers' financial data. No SQL injection, no malware, just a basic access control failure.
This type of bug — Broken Access Control — is consistently ranked as the #1 risk on the OWASP Top 10 because it's so common and devastating.
Access control ensures users can only do what they're authorized to do. When this breaks down, attackers can:
- Read or modify other users' data
- Escalate privileges (e.g., from "user" to "admin")
- Bypass business logic restrictions
OWASP data consistently shows Broken Access Control as one of the most reported categories across real-world applications.
What Is Broken Access Control?
Broken Access Control occurs when an application fails to enforce proper restrictions on what authenticated users can do.
It's different from authentication (verifying identity). Access control deals with authorization — what you're allowed to do after login.
Types of Broken Access Control
-
Insecure Direct Object References (IDOR)
- Accessing resources directly by changing identifiers.
- Example:
https://app.com/orders/123→ change123to124to view another user's order.
-
Vertical Privilege Escalation
- A regular user performing admin-only actions.
- Example: calling
/admin/deleteUseras a standard user.
-
Horizontal Privilege Escalation
- One user accessing another user's resources.
- Example: reading another user's messages.
-
Force Browsing
- Accessing hidden or unlinked pages.
- Example: guessing
/beta/new-featureendpoint.
-
Client-Side Enforcement
- Relying on front-end code to hide or disable actions, without server-side checks.
Related: This is often a sign of Insecure Design where security wasn't considered in the architecture.
Real-World Examples
- GitHub (2012 IDOR bug): An attacker discovered they could change email addresses of other users via IDOR, leading to account takeovers.
- Facebook (bug bounty 2020): Researchers found multiple IDOR issues allowing them to view private posts and messages.
- Fintech apps: Numerous cases where changing
account_idin API calls revealed other users' balances.
These aren't obscure attacks — they're basic mistakes in enforcing who can access what.
Why It Matters
- Common: Access control logic is custom-built in most apps, making it error-prone.
- High Impact: Leads directly to data breaches, fraud, and compliance failures.
- Expensive: Breaches from access control failures can lead to regulatory fines (GDPR, HIPAA).
Put simply: if authentication is the front door, broken access control is leaving the back door unlocked.
How to Prevent Broken Access Control
Enforce Authorization Server-Side
- Never rely on client-side checks (e.g., hiding a button in UI).
- Always verify permissions on the backend before performing actions.
Apply Principle of Least Privilege
- Give users only the permissions they absolutely need.
- Avoid "superuser" defaults.
Use Role-Based and Attribute-Based Access Controls
- Define roles clearly (admin, manager, user).
- Use attributes (department, resource ownership) to enforce finer-grained rules.
Protect Object References
- Don't expose raw identifiers if possible (use opaque references).
- Validate object ownership before returning data.
Add Rate Limits and Logging
- Rate-limit sensitive actions (e.g., password resets).
- Log access failures and alert on anomalies.
Tools for Detection
- Rafter: Scans for insecure endpoints, misconfigurations, and risky patterns.
- OWASP ZAP: Open-source penetration testing tool.
- Burp Suite: Widely used for manual/automated access control testing.
- Automated Tests: Write unit and integration tests for role-based access rules.
Conclusion
Broken Access Control is the #1 OWASP Top 10 risk for a reason: it's common, devastating, and easy to miss.
To recap:
- It happens when apps fail to enforce what users are allowed to do.
- IDOR, privilege escalation, and force browsing are common variants.
- Fixes include server-side checks, least privilege, and strong logging.
Next Steps:
- Audit your current access control implementation
- Implement server-side authorization checks
- Run a Rafter scan today to check if your repo is exposed to Broken Access Control issues — before attackers find them
Related Resources
- OWASP Top 10: 2026 Developer Guide
- API Keys Explained: Secure Usage for Developers
- Exposed API Keys: The Silent Killer of Projects
Frequently Asked Questions
What are common examples of broken access control?
Insecure Direct Object Reference (IDOR) is the textbook example: an endpoint like /orders/1234 returns another customer's order because the server checks that a valid ID was supplied but never checks that the requesting user actually owns that order. Vertical privilege escalation—a standard user reaching an admin-only route—and force-browsing to an unlinked page are the other common patterns. In modern APIs, the identical flaw goes by a different name: Broken Object Level Authorization, or BOLA.
What is the difference between IDOR and BOLA?
IDOR is the general term for accessing a resource by manipulating an identifier the application trusts without verifying ownership, and it applies to web apps and APIs alike. BOLA is the name the OWASP API Security Top 10 gives to the identical failure in API endpoints specifically, and it has topped that list in both its 2019 and 2023 editions. In practice, treat them as the same bug with two names: any endpoint that accepts an identifier needs a server-side ownership check, whether it is called from a browser or an API client.
How do you test for broken access control?
Manual testing means creating two low-privilege test accounts and swapping their session tokens or object IDs against each other's requests; if account A can read, edit, or delete anything belonging to account B, authorization is broken. Automated coverage means writing integration tests that assert every endpoint returns a 403 (forbidden) response for out-of-scope users, and dynamic scanners such as OWASP ZAP or Burp Suite can automate the ID-swapping part of this at scale. Neither approach replaces the other—scanners catch missing checks fast, but only a human reviewing the business logic catches rules a scanner cannot know, like whether a manager should see a subordinate's records.
How do you prevent broken access control?
Enforce every authorization check server-side, never in client-side JavaScript or a hidden UI element, since a client-side check can always be bypassed with a modified request. Apply the principle of least privilege by default, verify object ownership on every request instead of trusting an identifier the client supplies, and centralize authorization logic in one place rather than scattering it across handlers. Automated review helps too, especially as agents generate a growing share of this code: Rafter runs in CI at the pull request stage—static analysis, software composition analysis, and secret scanning—which will not replace a dedicated authorization test suite but does catch adjacent risks, like a hardcoded admin bypass or a leaked credential, before they merge next to a missing permission check.
Is broken access control still #1 on the OWASP Top 10 in 2026?
Yes. The current official release is the OWASP Top 10:2025, published in late 2025, and Broken Access Control (A01) held the position it has occupied since the 2021 edition—OWASP's contributed data found some form of it in 100% of applications tested, the highest of any category. There is no newer official edition as of mid-2026, so A01 remains the risk every team should address first.