Loading
Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
What each category in the OWASP Top 10 actually means in practice, and where it tends to show up in real applications, not just the textbook definition.
The OWASP Top 10 gets cited constantly, in pentest reports, security questionnaires, compliance checklists, but the one-line category names hide a lot of nuance about what actually shows up in real applications. This is the 2025 edition, OWASP's first update since 2021: two brand-new categories, one 2021 category folded into another, and several renamed or reranked. Here's what each category actually looks like in practice.
Consistently the most common finding across real assessments, and #1 for the fourth consecutive edition running. In practice this rarely looks like a missing login screen, it's an endpoint that checks whether you're authenticated but not whether you're authorized for this specific resource: changing an ID in a URL or API request and getting back another user's data. This is the single highest-value thing to test for in almost any application. Server-Side Request Forgery, which had its own standalone category in 2021, was folded into Broken Access Control for 2025, structurally it's the same failure, an application trusting a request it shouldn't, just aimed at internal infrastructure instead of another user's data. See our deeper look at broken access control and IDOR and at SSRF specifically.
Default credentials left in place, verbose error messages leaking stack traces, unnecessary features or ports left enabled, outdated dependencies with known defaults. Moved up three places for 2025, now the #2 most common category, which tracks with what shows up passively from the outside: this overlaps heavily with what our Domain Footprint Analyzer checks for, since many misconfigurations are visible without any active exploitation at all.
Brand new for 2025, and a genuine expansion in scope rather than a rename, it absorbs what 2021 called "Vulnerable and Outdated Components" (using a library with a known CVE) and broadens it to the whole software supply chain: a compromised build pipeline, a malicious package update, a CI/CD step that pulls in unverified third-party code. It's not enough anymore to just patch known-vulnerable dependencies; knowing what's actually in the build process, and whether it can be trusted, is now its own category. This is exactly the risk our Secure Code Review service checks for, since it requires actually knowing what's installed and how it got there, not just what was intentionally added.
Sensitive data transmitted or stored without adequate protection, plaintext passwords in a database, weak or homegrown hashing, secrets committed to source control, TLS misconfigurations. The fix is rarely "add more encryption", it's using well-vetted, standard implementations instead of custom ones, and knowing which data actually needs protecting.
SQL injection is the famous example, but the category covers anything where untrusted input gets interpreted as code or a command, NoSQL injection, OS command injection, cross-site scripting, LDAP injection. Parameterized queries and proper input handling solve this class almost entirely; it persists mostly in legacy code and string-concatenated queries that predate the fix being common knowledge. See our deeper looks at SQL injection and cross-site scripting specifically.
A category that's different from the others, it's not an implementation bug, it's a missing control at the architecture stage. Rate limiting that was never designed in, a password reset flow with no rate limiting or account lockout, a multi-step process with no server-side state validation. Insecure design can't be patched the way an injection bug can, it needs to be designed out.
Weak password policies, missing multi-factor authentication, session tokens that don't expire or get properly invalidated on logout. Renamed from 2021's broader "Identification and Authentication Failures" to sharpen the focus specifically on authentication itself. Authentication is one of the few places where a single flaw can undermine every other control in the application, it's worth disproportionate scrutiny relative to its size.
Trusting a CI/CD pipeline, plugin, or auto-update mechanism without verifying its integrity, or insecure deserialization that lets an attacker manipulate encoded data. Distinct from supply chain failures (A03) in that this is about trust boundaries below the supply chain itself, the checks (or missing checks) once code and data are already inside the pipeline. Signed commits, verified dependencies, and integrity checks on auto-updates are the standard mitigations.
Not a vulnerability in the traditional sense, but a force multiplier for every other one, if a breach isn't logged and an alert never fires, it isn't detected until the damage is already done. Renamed from 2021's "Logging and Monitoring" to put the emphasis where it actually matters for incident response: not just that an event was recorded somewhere, but that it actually triggered action. This is the difference between a contained incident and a prolonged one.
The other brand-new category for 2025. It covers what happens when an application fails to prevent, detect, or properly respond to an unusual or unexpected condition, everything from a null pointer dereference and a divide-by-zero error to a stack trace that leaks sensitive data in an unhandled exception, or a partially-completed transaction that leaves data in an inconsistent state. Much of this used to get waved off as a "code quality" issue rather than a security one; giving it its own category reflects how often error-handling gaps turn out to be exploitable in practice.
None of these are exotic. The pattern across all ten is the same: a control that exists in theory but wasn't actually enforced everywhere it needed to be. That's what manual testing is for, not finding esoteric zero-days, but systematically checking that the controls you think you have are actually there. See our Web & API Security and Secure Code Review services for how we test against this list directly, or the official OWASP Top 10:2025 for the full reference. For categories that deserve their own deeper look, see our pieces on SQL injection and cross-site scripting (both A05), SSRF (now folded into A01), and broken access control and IDOR, the category that's actually topped this list since 2021 (A01).
Tell us about your environment and goals, we'll help you scope the right engagement.