Key Takeaways
- Broken access control remains the number one category in OWASP’s Top 10 2025 release, the fourth consecutive edition where it has held the top spot.
- Security misconfiguration jumped from fifth place to second, driven largely by cloud configuration complexity rather than code level bugs.
- OWASP’s own reported average incidence rate for broken access control is 3.73 percent across 40 mapped CWEs, though several third party summaries describe it more loosely as present in nearly every application tested, a different metric worth understanding before citing either number.
- Both leading categories are business logic and configuration problems, not the kind of flaw an automated scanner reliably catches.
Broken access control has topped OWASP’s Top 10 for four consecutive editions now, and the 2025 release, published in November 2025, confirms it is not going anywhere. If your SaaS product has ever passed an automated vulnerability scan clean and still had a real access control gap sitting underneath, this is why.
What Changed and What Did Not
OWASP’s 2025 update, its first since 2021, kept broken access control at number one and absorbed server side request forgery directly into that category, treating SSRF as fundamentally an access control failure rather than a standalone issue. The full OWASP Top 10 2025 release documents all ten categories in detail. The bigger shift was security misconfiguration, which jumped from fifth place to second, reflecting how much cloud infrastructure complexity has grown since the last release. Software supply chain failures also entered as a new category, expanding on what used to be a narrower “vulnerable components” classification.
Two different numbers circulate for how common broken access control actually is, and the distinction matters if you are going to cite either. OWASP’s own published figure is an average incidence rate of 3.73 percent across the 40 CWEs mapped to this category, that is the average share of tested applications carrying any single one of those specific weaknesses. Several third party writeups describe the category more broadly as present in close to 100 percent of tested applications, which appears to measure whether an application had at least one instance of any access control flaw at all, a meaningfully different and much broader metric. Both numbers are real, they are just answering different questions.
Why This Category Refuses to Go Away
Broken access control and security misconfiguration share something that most other vulnerability classes do not, they are rarely a single line of broken code. An access control flaw is usually a business logic gap, user A can view user B’s invoice by changing an ID in a URL, or an internal admin endpoint that forgot to check role permissions on a new feature. A misconfiguration is often a cloud setting, a storage bucket left public, an IAM policy scoped too broadly, rather than a vulnerable software version with a known CVE.
This is precisely the category of finding an automated scanner is structurally weak at catching. A scanner can flag a missing security header or an outdated library with a known CVE reliably. It has a much harder time understanding that your application’s authorization logic lets a standard user reach an admin only function, since that requires understanding what the application is supposed to do, not just what code is present.
Curious whether your own application has an access control gap sitting underneath a clean automated scan? Book a scoping call and we will talk through what manual testing would actually cover for your specific setup.
What This Means for SaaS Startups Specifically
Authentication vulnerabilities SaaS teams run into tend to cluster around the same handful of patterns, missing authorization checks on API endpoints added after the initial build, role based access control that was implemented for the UI but not enforced server side, and multi tenant systems where one tenant’s data boundary was not tested against every possible role combination. None of these show up reliably in a vulnerability scan, because none of them are a known, signature matched flaw. They are specific to how your application’s logic was built.
This is also why the manual versus automated distinction matters more than it sounds like it should when you are comparing pentest quotes. A manual penetration test spends real tester hours trying to break your authorization logic the way an actual attacker would, testing role boundaries, tenant isolation, and business logic paths that a scanner has no framework for evaluating. For a SaaS penetration test specifically, this is usually where the majority of testing time and the majority of meaningful findings come from.
Frequently Asked Questions
Is broken access control really the most common vulnerability in 2026? It has held the top spot in OWASP’s Top 10 for four straight editions, including the November 2025 release. The exact prevalence number depends on which metric is being cited, OWASP’s own average incidence rate is 3.73 percent, while broader measures describing at least one instance per application run much higher.
Can automated vulnerability scanning catch access control flaws? Scanners are effective at known, signature based vulnerabilities like outdated software versions or missing security headers. Business logic flaws, like a user reaching data or functions their role should not permit, generally require a human tester who understands what the application is supposed to do.
Why did security misconfiguration jump to second place in OWASP’s 2025 list? OWASP attributes the rise largely to growing cloud infrastructure complexity, more configurable services and infrastructure as code create more opportunities for a setting to be left wrong, distinct from a code level vulnerability.
If your last security review was an automated scan rather than manual testing, book a scoping call and we will walk through what a manual assessment would actually cover.
Packet33 is a penetration testing and compliance advisory firm serving SaaS and HealthTech startups in the US, Canada, and UK.
Mohamed is the founder of Packet33. He worked as a cybersecurity analyst before launching the firm and now leads an OSCP-certified team serving SaaS and HealthTech startups in the US, Canada, and UK.