The OWASP Top 10 Explained in Plain Language

The OWASP Top 10 is a consensus list, maintained by the Open Worldwide Application Security Project, of the ten most critical web application security risks. The current edition, OWASP Top 10:2021, ranks broken access control first and is widely used as a baseline checklist for developers, testers and scanners. It describes categories of risk, not individual bugs.

Its value is as a shared vocabulary and a coverage map: if your testing touches all ten categories, you have addressed the risks the field agrees matter most. Its limit is that it is a floor, not a ceiling, and clearing it is not a certificate of security. Here is each category in plain terms, with what a passive scanner can and cannot see.

A word on how the list is built, because it explains why it looks the way it does. OWASP compiles it from data contributed by many organisations, covering hundreds of thousands of applications, supplemented by a community survey that captures risks the raw data underrepresents because they are hard to test for automatically. That two-track method is why a category like Insecure Design can appear despite being difficult to measure: practitioners know it matters even where tooling struggles to quantify it. The 2021 edition reorganised several categories, merged others, and promoted Server-Side Request Forgery, so always cite the edition you mean, the numbers are not stable across versions.

The ten categories

A01: Broken Access Control

The top risk. It covers every case where a user can act outside their intended permissions: viewing another customer's order by changing an ID in the URL, reaching an admin page without being an admin, or editing a record they should only read. The classic example is insecure direct object reference: /invoice?id=1043 works, so the attacker tries 1044. A passive external scan cannot find this, because the malicious request looks entirely normal. It needs authenticated, logic-aware testing.

A02: Cryptographic Failures

Previously "Sensitive Data Exposure." It covers weak or missing encryption for data in transit and at rest: plain HTTP, deprecated TLS, weak ciphers, unsalted password hashes, secrets in source. The transport half is highly observable, which is why our deprecated TLS check and the transport work in SSL and TLS explained map onto it. The at-rest half, how you store passwords and keys, is internal and needs review.

A03: Injection

Untrusted input interpreted as a command. It includes SQL injection, command injection, and cross-site scripting (folded into injection in 2021). The fix pattern is consistent: separate code from data with parameterised queries and contextual output encoding. Confirming injection requires sending payloads, so it belongs to active scanning; a passive scan can only flag suspicious signals.

A04: Insecure Design

New in 2021, and important: it names flaws that are baked into the design, not the code. A password-reset flow that leaks whether an account exists, or a checkout that trusts a client-side price, is insecure by design even if every line is written correctly. No scanner finds this; it takes threat modelling before code is written.

A05: Security Misconfiguration

The most scanner-friendly category, and one of the most common in the wild. Missing security headers, default credentials, verbose error pages, directory listing, and unnecessary features left enabled all live here. This is precisely what a passive scan excels at: our checks for CSP, framing and exposed files map directly onto A05, and the fixes are in HTTP security headers explained.

A06: Vulnerable and Outdated Components

Running a library, framework or server with a known vulnerability. An old jQuery, an unpatched CMS, a web server with a public CVE. Client-side components are directly observable, which is why the outdated-library check and the guide on outdated JavaScript tie straight to A06. Prioritising the resulting CVEs is the subject of CVE and CVSS explained.

A07: Identification and Authentication Failures

Weaknesses in proving who a user is: permitting weak passwords, no protection against credential stuffing, session tokens that do not rotate or expire, or predictable session IDs. Some signals, such as a login form that allows unlimited attempts, are partly observable; the core logic is not.

A08: Software and Data Integrity Failures

Trusting code or data whose integrity was never verified: an update mechanism without signature checks, a CI/CD pipeline that pulls unpinned dependencies, or a page loading a third-party script with no Subresource Integrity hash. The SRI portion is observable; the pipeline portion is internal.

A09: Security Logging and Monitoring Failures

Not an attack but the absence of the ability to detect one. If a breach leaves no trace in your logs, or nobody watches them, an intruder can operate undisturbed. This is entirely internal to your operations and cannot be scanned from outside; it is a process gap, not a request you can send.

A10: Server-Side Request Forgery (SSRF)

Making the server fetch a URL the attacker controls, so it reaches internal systems the attacker cannot reach directly, cloud metadata endpoints being a notorious target. SSRF rose to its own category in 2021 as cloud architectures made it more damaging. Proving it requires active testing.

How to use the list

1. Scan for the observable categories first, since they are cheap and common. The website scanner covers most of A02, A05 and A06.
2. Review the logic categories (A01, A04, A07, A09) with authenticated testing and threat modelling.
3. Fix by root cause, since one change, say, parameterised queries, closes many A03 findings at once.
4. Re-test after fixes and after every release.

The Top 10 is the backbone of the website security hub, and understanding what a scan can prove against it starts with what a vulnerability scan is. Treat the list as a map of where to look, not a box to tick.

A recurring theme across the categories is worth making explicit, because it shapes how you should divide your effort. The flaws a scanner finds are, broadly, the flaws that are visible from the network, and those cluster in configuration and known-component problems, A02, A05 and A06, which are common, cheap to find and cheap to fix. The flaws that require understanding what the application is for, A01 access control, A04 design, A07 authentication logic, are the ones that cause the largest breaches and the ones automation cannot see. That asymmetry has a practical consequence: automated scanning should be continuous and cheap, so that the observable half is never your weak point, which frees your scarce human review time to concentrate entirely on the logic half, where it is the only thing that works. Teams that invert this, paying experts to hand-check for missing headers while never modelling their access-control rules, spend the most on the least and leave the expensive risks untouched.

One caution about how the list is used in practice. Because the Top 10 is famous, it is easy to let it become the whole of an application security programme, to treat "we checked the Top 10" as equivalent to "we are secure." That is a misreading of its own authors' intent. It is deliberately a top ten, an awareness document that gets teams past the most common mistakes; it is not exhaustive, and a serious flaw in your application may not map cleanly to any category. For requirements you can test against systematically, OWASP itself points to the Application Security Verification Standard, which is far more granular. Use the Top 10 to start conversations and structure a first pass, then go deeper than it where your application's risk actually lives. Read well, it is a lens that keeps a team looking at the right things; read badly, it becomes a checklist that lets a team stop looking too soon. The difference is entirely in how you hold it.