Broken Access Control
Broken access control occurs when an application fails to properly enforce restrictions on what authenticated users are allowed to do, enabling them to access unauthorized resources or perform unauthorized actions.
Understanding Broken Access Control
Access control determines what an authenticated user is permitted to do. When these controls are broken, users can view other users' data, modify records they should not have access to, escalate their role from regular user to admin, or perform administrative functions. The OWASP Top 10 has ranked broken access control as the number one web application security risk.
Common patterns include IDOR (insecure direct object references) where changing an ID parameter in a URL reveals another user's data, missing function-level access control where admin endpoints are accessible to regular users, metadata manipulation where users modify their own role or permissions in JWT claims, and horizontal privilege escalation where one user accesses another user's resources of the same privilege level.
The root cause is typically that authorization checks are implemented inconsistently — some endpoints enforce them, others do not. This is especially common when access control logic is embedded in individual route handlers rather than applied systematically through middleware. A single forgotten check on one endpoint can expose the entire resource.
Effective access control requires a deny-by-default approach (nothing is accessible unless explicitly permitted), centralized authorization logic applied as middleware, thorough testing of every endpoint with different user roles, and audit logging to detect unauthorized access attempts.
Why This Matters for Vibe-Coded Apps
Broken access control is the most prevalent vulnerability in vibe-coded applications. AI generators focus on making features work for the happy path — the logged-in user accessing their own data. They rarely implement checks for what happens when a user tries to access another user's data by changing an ID in the URL or API request.
When an AI builds a CRUD API for a resource like user profiles or posts, it typically generates endpoints like GET /api/posts/:id without verifying that the requesting user owns that post. Always add ownership checks: verify that the authenticated user's ID matches the resource's owner before returning or modifying it. In Supabase, RLS handles this at the database level, but custom API endpoints need explicit checks.
Real-World Examples
First American Financial Data Leak (2019)
A simple IDOR vulnerability exposed 885 million records containing bank account numbers, Social Security numbers, and mortgage documents. Anyone could access any document by incrementing a sequential ID number in the URL — no authentication required.
Parler Data Scrape (2021)
Parler's API assigned sequential post IDs with no access control or authentication on the retrieval endpoint. Researchers used this to download the entirety of Parler's content — including deleted posts and GPS-tagged media — by simply iterating through sequential IDs.
Facebook View As Exploit (2018)
A combination of broken access control vulnerabilities in Facebook's "View As" feature allowed attackers to obtain access tokens for other users' accounts. The flaw affected approximately 50 million accounts and resulted in a forced logout of 90 million users.
Frequently Asked Questions
Why is broken access control ranked #1 in OWASP Top 10?
Broken access control moved to the top position because it is the most commonly found vulnerability in real-world applications. Unlike injection attacks which modern frameworks help prevent, access control must be manually implemented for each resource and action. There is no framework default that automatically prevents one user from accessing another's data — developers must explicitly code these checks, and the complexity means they are frequently missed.
How is broken access control different from authentication bypass?
Authentication verifies identity (who are you), while access control enforces permissions (what are you allowed to do). Authentication bypass means skipping the login entirely. Broken access control means a logged-in user can do things they should not be permitted to do, like accessing admin pages or other users' data. You can have perfect authentication but completely broken access control.
How do I test for broken access control?
Create test accounts at each role level (admin, user, guest). For every endpoint, test it with each role to verify the response matches expectations. Try accessing another user's resources by changing IDs in URLs and request bodies. Test vertical escalation by attempting admin actions with a regular user token. Automated tools like Burp Suite's Authorize extension can compare responses between users to find inconsistencies.
Should access control be in the database or application layer?
Use both for defense in depth. Database-level controls like PostgreSQL RLS provide a security floor that cannot be bypassed by application bugs. Application-level controls provide flexibility for complex authorization logic (e.g., role hierarchies, resource-specific permissions). If you use Supabase, RLS should be your primary defense, supplemented by application-level checks for complex business rules.
Is Your App Protected?
VAS automatically scans for vulnerabilities related to broken access control and provides detailed remediation guidance. Our scanner targets issues common in AI-generated applications.
Scans from $5, results in minutes. Get actionable fixes tailored to your stack.
Get Starter Scan