Broken access control: still the number one web vulnerability
When OWASP last reranked its Top 10, broken access control moved up to the number one spot, and it has stayed the defining web vulnerability class since. That is not an accident of one bad year. Access control is the category that automation is worst at finding and that AI-assisted development is best at breaking, which is a uniquely bad combination.
What broken access control actually means
Access control is the set of rules deciding who can do what: which users can see which records, perform which actions, reach which functions. It is broken when those rules are missing, incomplete, or enforced in the wrong place. The family includes IDOR (reaching objects that are not yours), privilege escalation (becoming an admin you should not be), missing function-level checks (calling an endpoint the UI never showed you), and trusting access decisions the client could tamper with.
Why it is the hardest thing to scan for
A scanner can recognize a known-vulnerable library or a missing security header because those are patterns. It cannot reliably tell whether a given user should be allowed to perform a given action, because that depends on your application's rules, which the scanner does not know. Access control is business logic, and business logic is exactly what pattern-matching cannot infer. This is why broken access control is simultaneously the most common serious finding and the one tools miss most often.
Most vulnerabilities are about code doing something it should not. Broken access control is about code failing to ask whether it should at all.
Why modern development keeps producing it
Access checks are invisible when everything goes right. When the developer (or the AI assistant) tests the feature, they are logged in as the right user, so everything works, and the missing check is silent. AI-generated code is especially prone to it: the model produces the data-fetching logic flawlessly and omits the authorization scope, because the scope is the part that never shows up when the code runs correctly. We cover that pattern in what AI-generated code gets wrong about security, and the most common instance in what is IDOR.
How it is actually found
You find broken access control by testing authorization directly and adversarially: with multiple accounts at different privilege levels, deliberately attempting actions and reaching objects that should be forbidden, and proving each boundary either holds or fails. That requires real accounts and the judgment to know what should be off-limits, which is exactly the work a thorough penetration test exists to do.
Uvy makes access control a primary target: it tests with multiple roles, probes function- and object-level authorization across the authenticated surface, and proves each broken boundary with the request that crossed it. See how it works.