There is no single OWASP Top 10 because there is no single attack surface. An API exposes objects and functions, a cluster exposes roles and workloads, an LLM application crosses prompts, tools, and memory. The Web list remains an important reference, not an identity document for every system.

The OWASP project today maintains around fifteen Top 10 projects with very different levels of maturity: some are data-driven flagships, others are drafts or historical archives preserving more idea than currency. Treating them as equivalent produces exactly the kind of security you do not want: an elegant checklist and an attack surface nobody covers.

The hierarchy of lists 🧭

Not all lists carry the same weight, and knowing the difference avoids both fetishism and snobbery:

Tier	Lists	What to expect
Core	Web 2025, API 2023, Mobile 2024, LLM 2026, Kubernetes, CI/CD	Focus your analysis here
Architectural	Cloud-Native, Serverless, Client-Side	Useful ideas, dated or never-finalized editions
Cross-cutting	Privacy, Data Security	Compliance and data-lifecycle risks
Vertical	ML, Low-Code/No-Code, Desktop, Smart Contract	Only for specific stacks
Proto-taxonomies	Cloud-Native interim, Serverless, Client-Side	Candidate lists: concepts, not requirements

The 2025 Web Top 10 is built on data from about 2.8 million applications; the 2022 CI/CD list has no equally solid data model and several lists are explicitly “draft” or “interim”. Maturity is a filter. A historical list may offer sound concepts, but citing it as a requirement in this year’s audit is an elegant way to lose credibility.

Editions and lifecycles ⏳

Editions are not simultaneous: Web is 2025, API 2023, Mobile 2024, LLM 2026; Kubernetes exists in two numberings (2022 and 2025) that coexist on the official site; CI/CD sits at 2022 but remains the reference for pipelines. Treating “current lists” as if they shared a single calendar is an error you notice immediately in a vulnerability board. The question to ask is not “which list do I use?” but “which edition answers the layer I am looking at, and what source feeds it?”.

The most valuable methodological note sits inside the 2025 Web Top 10: eight categories are selected from test data and two from expert judgment, because automated tests cannot capture them. The point is not whether you believe those two entries: it is knowing that the lists mix measured prevalence and estimated emerging risk, and behaving accordingly when you use them to decide.

The main lenses 🔍

Domain	Useful list	What makes the problem different
Web application	OWASP Top 10 Web 2025	Requests, session, business logic, browser
API	OWASP API Security 2023	Objects, properties, functions, service trust
Mobile	OWASP Mobile 2024	Device, local storage, SDKs, permissions
LLMs and agents	OWASP LLM 2026 + Agentic 2026	Hostile content, output, tools, autonomy
Kubernetes and CI/CD	OWASP Kubernetes and CI/CD	Machine identity, policy, images, pipelines

Each list is a projection of the same risk space onto a specific domain. Mobile 2024 devotes a category to hardcoded credentials (M1) because you cannot trust the client; the Web Top 10 needs no equivalent line because the server holds the secrets. The API Top 10 treats injection differently from the Web list — it even removed it in the 2023 edition, because it is “agnostic to the API” and need not be restated, while object-level authorization is the dominant risk. The emergence of an agent list does not mean classic security disappeared: it signals that instructions, data, and executable capabilities have new boundaries.

You have probably heard of the OWASP Top 10 for agentic applications (2026): it was born as complementary to the LLM Top 10. The LLM list covers model risk (prompt injection, output handling); the agentic one covers what happens when you give the model a goal, memory, tools, and permanent permissions (goal hijacking, tool abuse, identity and privileges). Two lists, two levels, no conflict.

Choosing the lens 🎯

Start from architecture, not the list title. A SaaS product with APIs, mobile app, RAG, and Kubernetes needs multiple references; none covers everything. Consider maturity and edition date too; a historical list may provide useful concepts without being a current requirement.

The practical method:

1. List the system’s real layers: client, API, orchestrator, pipeline, AI components.
2. Match one list per layer, without forcing a single list onto everything.
3. Annotate the gaps: a list that does not cover your domain is not an omission by the project; it is an invitation to use the lens next to it — not the sacred book in place of the code.

Classic anti-patterns: using only the Web Top 10 for a serverless system, declaring “we are OWASP compliant” without saying which of the fifteen lists, or importing another organization’s framework without checking it against your architectures.

A concrete example. An e-commerce service has checkout and an admin panel (Web Top 10), inventory and payments exposed via REST (API), a cluster with data tenancy (Kubernetes), a pipeline that signs artifacts (CI/CD), and maybe a RAG-based support chat (LLM). Five lists, one system: on the day an incident asks “where is the hole?”, the answer will not be in the list you like best.

When the list is not enough ⚠️

Some OWASP projects have stayed at candidate-list level. Cloud-Native Application Security, Client-Side Security, and even more so Serverless have never reached a numbered final version: the Serverless document reuses the 2017 Web categories as an “interpretation” pending an official list that never came. They are not useless: they are proto-taxonomies that illuminate the risks of a domain while the project has yet to systematize them.

Two tricks for using the ecosystem well:

• Date the edition: when assessing the risks of your Kubernetes workload, the 2022 and 2025 numberings coexist; picking one without annotating the other will confuse the next audit.
• Connect the projects: Low-Code/No-Code explicitly cites “A06:2021 Vulnerable and Outdated Components” as inspiration, and the Privacy Top 10 declares that it includes the Web Top 10 within it. When projects talk to each other, follow the thread.

Top 10 lists are not a vulnerability catalogue to tick off. They are questions to ask of the right system.

Continue with levels of abstraction before comparing categories line by line, or jump to the unified taxonomy.