Comparing one Top 10 with another is useful only if you do not mistake a cause for a result. OWASP lists deliberately mix different levels: that makes them operational, but also makes false equivalences easy.

The scale of levels 📊

Level	Question	Example
Weakness	What structural defect exists?	Missing server-side authorization
Vulnerability	Where is it exploitable?	Endpoint returning another user’s order
Threat	Who can abuse it and how?	Attacker changes an ID
Control	What prevents or detects it?	Ownership check, logs, authorization tests
Impact	What happens on failure?	Exfiltration, fraud, unavailability

The scale is not decoration: it is the tool that stops you from calling a weakness a “data breach” or “prompt injection” a vulnerability you can patch. Each row answers a different question and requires different controls. A weakness is eliminated by changing the design; an impact is mitigated by detection and response.

Why the lists mix levels 🌀

The confusion is not a flaw of the lists: it is an effect of their method. The 2025 Web Top 10 selects eight categories from empirical data (about 2.8 million tested applications) and two from an expert survey — logging/alerting and supply chain — because automated tests detect them poorly. This means that even within the same list, some rows measure real prevalence and others are expert judgment on emerging risk. They do not carry the same weight: that is normal. Behaving as if they did is the problem.

What is more, some categories describe impacts or attack classes rather than causes. If a data-lifecycle list puts “Data Breaches” and “Malware/Ransomware” next to “Weak Cryptography”, you are looking at different levels on a single page: the first row is the outcome of an attack, the third is a possible cause. Managerial? Convenient. Rigorous? No.

The outliers teach something 🧠

Web A02 describes a class of insecure configurations; API6 a business-flow design failure; K01 and K09 are configurations; some data lists describe mostly outcomes. Prompt injection is an attack technique to manage, not a weakness you “patch” by perfectly separating data and instructions.

2025 introduced two more mixed levels among the A-items. A10 (Mishandling of Exceptional Conditions) is a behavioral category under anomalous conditions: errors that corrupt state, reveal details, or bypass controls. It is not a classic code weakness — it is closer to an operational failure. A03 (Software Supply Chain Failures) is an ecosystem category: hard to surface in automated tests precisely because it crosses repositories, build runners, and external artifacts, which is why OWASP promoted it through the survey rather than the data. These are rows to read with the scale at hand.

Use the scale, do not worship it ⚖️

When an item sits at a level different from the one you expected, annotate it and choose suitable controls instead of forcing it into a box. The right question is never “is it the same thing?”, but “at which level does it manifest here?”.

Take access control: the weakness (“a server-side check is missing”), the vulnerability (“the GET /api/v1/orders/{id} endpoint is exploitable as BOLA”), the threat (“an attacker enumerates IDs”), the control (“ownership check, rate limit, authorization tests”), and the impact (“customer order exfiltration”) occupy five different rows of the scale yet all end up under A01 in the Web list. None of the answers is wrong: they are answers to different questions.

The same holds for supply chain: the rigorous separation between “vulnerable component” (a library with a CVE — weakness) and “component compromised at the source” (a poisoned pipeline — threat and impact together) is the difference between a fix and an incident. The 2025 taxonomy formalizes it by distinguishing A03 (external ecosystem) from A08 (your artifact’s integrity), which operate on different planes.

Abstraction differences also exist across projects. The Desktop App Security 2021 mirrors the pre-2021 Web Top 10 structure (separate entries for “Sensitive Data Exposure”, “Broken Authentication”, and “Using Components with Known Vulnerabilities”), while the Web 2025 consolidated root causes and absorbed SSRF into A01. Two contemporary projects describing the same problem at different levels: the scale resolves the “why do they call them differently?” question.

A complete example: prompt injection 🔬

Let’s walk the scale with prompt injection, the outlier everyone keeps in their pocket. The weakness is structural: the model does not separate instructions and data on the same channel. The vulnerability manifests when hostile content arrives from a page indexed in the RAG and is read as context. The threat is an attacker who controls a page hoping the agent will consume it. The controls are restricted capabilities, human confirmations, data isolation, and adversarial eval — not an upstream filter. The impact can be an unauthorized refund or data exfiltration.

Annotating the right row here is not pedantry: it is what stops you from selling “an anti-prompt-injection filter” as a solution. The filter touches only the threat; the weakness remains, waiting for the wrong page.

A practical rule ✅

For every category ask: which property does it protect, what is the failure mechanism, which controls reduce it, and which impact remains possible? If you do this before comparing two lists, you will quickly see where the real equivalences are and where there is only a resemblance of names.

• I identify the level of every category I compare.
• I distinguish cause from impact in the concrete case.
• I choose controls by level, not by category name.
• I annotate outliers instead of forcing them into a box.
• I verify which edition and which method produced the row.

This lens prepares the unified taxonomy, an analytical proposal of this series, not an official OWASP classification. If you have not yet, start from the ecosystem to pick the right lists for your domain.