Access Control
Broken access control, the flaw behind most real breaches.
Broken access control is when your app fails to enforce who is allowed to do what: a user reads another user's data, an unauthenticated request reaches a protected endpoint, an ordinary account performs an admin action. It is the number one item on the OWASP Top Ten, and the most common serious finding in AI-built apps.
The rules exist in your head. The question is whether they exist in the code.
You know who is supposed to see and do what in your app. Broken access control is the gap between that intention and what the code actually enforces. It is the most common serious flaw because it is invisible: an app with no access control and an app with perfect access control look and behave identically to their legitimate users. The difference only appears when someone tries to do what they should not.
The forms it takes
Unprotected data is the broadest form: a table or endpoint that returns its contents to anyone with the public key, because no rule decides who may read it. This is what a missing row-level security policy or an open Firebase database produces, and it is the single most common serious finding we see.
Insecure direct object references, or IDOR, are the per-record version: the app fetches a record by an ID from the request without checking ownership, so changing the ID returns someone else's data. Privilege escalation is the role version: an ordinary user reaches an admin function because the check for admin was in the interface, not the server. Unauthenticated writes are the write version: a stranger inserts or alters records in tables like orders or payments, and the app treats the forged data as real.
Why AI-built apps are full of it
When an AI builder generates a feature, it writes the visible behaviour: fetch this, show that, save the other. The access check, the line confirming the caller is allowed to do the thing, is not part of the visible behaviour, so it is the part most often omitted. The feature works in the demo because the demo user is allowed, which hides that everyone else is allowed too.
Across the apps we have audited, this pattern is remarkably consistent. The most common serious finding is not exotic. It is an access check that was never written, sitting behind an app that works perfectly.
How to find it in your app
Start with the two-account test: log in as one user and try to reach another user's data and actions through every route you can find. Then test as no user at all: hit your endpoints and query your database with just the public key and see what answers. Then test as an ordinary user reaching for admin functions. Each of these targets one form of broken access control.
The checks are simple to describe and easy to get wrong at scale, because every endpoint and every table needs to enforce the right rule, and one missed spot is the whole exposure. Testing every one of them systematically is the core of our security audit.
Common questions.
- Why is broken access control ranked the number one risk?
- Because it is both the most widespread and among the most damaging. It exposes real user data and real actions directly, it requires little skill to exploit, and it appears in a large share of applications. OWASP moved it to the top of its list on exactly that evidence, and AI-built apps show the pattern even more strongly.
- How is this different from IDOR?
- IDOR is one specific form of broken access control, the per-record one where changing an ID returns someone else's data. Broken access control is the whole category, which also includes unprotected tables, privilege escalation and unauthenticated writes.
- Can you find broken access control in my app?
- Yes, it is the core of what our security audit looks for. We test every route, table and function for the access checks that should be there and are not.
Related services.
Let's build something real.
Tell us about your app or idea. You'll get a clear plan and a fixed quote back within 24 hours.