The OWASP Top10 is the closest thing application security has to a shared vocabulary — a periodically updated list of the most critical web application risk categories, maintained by the nonprofit Open Web Application Security Project and drawn from real-world vulnerability data contributed by security vendors and practitioners. It isn't a checklist of ten specific bugs; it's ten categories, each covering a family of related vulnerability patterns. Here's a working reference to what each category actually means and which type of tool — SAST, DAST, or SCA — is best positioned to catch it.
What is broken access control, and why does it top the list?
Broken access control covers any case where a user can act outside their intended permissions — viewing another user's data by changing an ID in a URL, accessing an admin function without admin rights, or bypassing an authorization check entirely. It tops the OWASP list because it's both extremely common and often invisible to automated tools that don't understand your application's authorization model; a broken object-level authorization bug looks like a perfectly valid API request to a scanner that doesn't know user A shouldn't be able to fetch user B's record. DAST tools can catch some instances through authenticated crawling with multiple test accounts, but the most reliable detection still comes from manual testing or IAST tools with real session context.
What counts as a cryptographic failure?
Cryptographic failures cover weak or missing encryption for sensitive data, both in transit and at rest — hardcoded encryption keys, deprecated algorithms like MD5 or SHA-1 used for password hashing, TLS misconfigurations, and sensitive data transmitted or stored in plaintext where it shouldn't be. This category was renamed from "sensitive data exposure" in the 2021 revision specifically to focus attention on the root cause (broken crypto) rather than just the symptom (data exposure). Static analysis tools are well-suited to catching hardcoded keys and deprecated algorithm calls directly in source code, while configuration scanners catch TLS and cipher suite issues.
How does injection still make the list after decades of awareness?
Injection — SQL injection, command injection, LDAP injection, and related patterns — persists because string concatenation into a query or command is still the fastest way to write the feature, and plenty of legacy code and quickly-shipped new code takes that shortcut anyway. The fix (parameterized queries, prepared statements, proper escaping) has been well understood for years, but injection remains exploitable wherever that guidance wasn't followed, which is still a lot of code. SAST tools are particularly effective here because they can trace user input from source to a dangerous sink directly in the codebase, flagging the pattern before it ever ships.
What's new about the "insecure design" category?
Insecure design, introduced in the 2021 revision, covers risks that come from missing or flawed security controls at the architecture level — problems no amount of clean coding can fix because the design itself doesn't account for the threat. Examples include a password reset flow with no rate limiting by design, or a multi-tenant system where isolation between tenants was never architected as a requirement. This category is explicitly not something a scanner catches after the fact; it requires threat modeling and secure design review earlier in the SDLC, which is why OWASP added it as its own category rather than folding it into implementation-level bugs.
Where do security misconfiguration and vulnerable components fit in?
Security misconfiguration covers default credentials left in place, verbose error messages leaking stack traces, unnecessary features enabled, and cloud storage left publicly accessible — largely operational and infrastructure issues rather than application code bugs. Vulnerable and outdated components is the category most directly addressed by software composition analysis: it covers using libraries and frameworks with known, unpatched CVEs, which is how a huge share of real breaches actually happen, not through custom exploit development but through unpatched, publicly known vulnerabilities in dependencies. Between these two categories and injection, you can see why a combined SAST, DAST, and SCA program covers meaningfully more of the OWASP Top10 than any single scanner type alone.
FAQ
How often does OWASP update the Top 10?
Roughly every three to four years — the list was last substantially revised in 2021, with community data collection for the next major revision ongoing; check owasp.org directly for the current official list.
Is the OWASP Top10 a compliance requirement?
Not on its own, but it's frequently referenced by compliance frameworks (PCI DSS explicitly requires addressing OWASP Top10 risks for payment applications) and is a common baseline auditors expect to see covered in an AppSec program.
Does covering the OWASP Top10 mean an application is secure?
No — it's a baseline for the most common risk categories, not a complete security guarantee; plenty of severe, application-specific logic flaws and business logic vulnerabilities fall outside these ten categories entirely.
What's the difference between the OWASP Top10 for web apps and the API-specific list?
OWASP maintains a separate API Security Top10 that covers risks more specific to API architectures, like broken object-level authorization and excessive data exposure through API responses — both lists are worth reviewing if your application exposes APIs. For more on tooling that maps to these categories, see our blog.