9/29/2025 • 4 min read
Broken Access Control: OWASP Top 10 Explained
Estimated reading time: ~12 minutes
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