OWASP Top 10 are not ten lists 📉
TL;DR: the question is not which Top 10 is the true one. The question is which part of your system you are looking at, and which one you are conveniently forgetting.
One list for every boundary 🗺️
The Web Top 10 is famous because the Web was long the centre of application software. Then APIs began exposing their own objects and functions, Kubernetes made the control plane an everyday surface, and LLMs added hostile instructions and executable tools to the party. Every technology built its own vocabulary of failures, and each OWASP working group collected it. The result is a family of lists, not an exception to the rule.
This is not fragmentation for sport. It is specialization. A BOLA is not an open admin route; permissive RBAC is not a badly validated JWT; prompt injection is not SQL injection wearing a different hat. Those who flatten them into a single checklist are not simplifying: they are hiding the mechanisms, and mechanisms are the only thing controls need to know about.
When the list lies 🤥
Lists “lie” — in the noble sense of the word — in at least three moments. They lie when you use them as a certificate of compliance: an app ticking every Web item can still have an API open like a corporate gate, because the Web list does not talk about exposed objects. They lie when you take them as a risk ranking for your context: the Top 10 measures prevalence over a global basket, not the risk of your specific domain; an app with a single exposed endpoint can have a huge risk in a category near the bottom of the list. And they lie when you read them as exclusive categories: the fact that prompt injection appears in the LLM list does not make it absent from your Web code that calls a model.
The funniest case is the fifth: by the time an entry becomes famous, attackers have already been working on it for three years, and the list — by definition — photographs the past. This is not a flaw of the lists: it is the nature of the cop who arrives after the brawl. The problem is when someone believes that arriving late means being on time.
There is also a fourth betrayal, the subtler one: lists are often used as department boundaries. “I handle Web security, you handle LLM, he handles Kubernetes”: the taxonomy becomes an organizational fence that justifies separate ownership over what is the same concept. The result is a chain whose links do not talk to each other: the access control policy written for the Web does not migrate to the API, the cluster’s RBAC ignores the agent’s excessive agency, and nobody notices that the breaking point is exactly the connection between departments. Lists are great as lenses, terrible as walls: those who use them to divide domains end up missing the risk that cuts across them.
Lists become useless when you use them to avoid thinking. They become powerful when you use them to ask better questions.
Parallel lists, not competitors 🔀
Some read the proliferation of lists as a succession war and get lost wondering which Top 10 will be the definitive one. It never will be. Parallel lists do not compete: they complete each other, because no single one covers the whole surface. The same concept changes house and disguises itself: access control is BOLA in APIs, permissive RBAC in Kubernetes, excessive agency in the LLM space. The principle is the same, the verification is not, and one list is never enough.
Those insisting on the single list are looking for the answer before understanding the problem. Those accepting the family of lists stop asking which one is true and start asking how to cross it: which property am I protecting, in which domain, with which mechanism. It is the shift from hunting for a certificate to building a map — and a map, as everyone knows, is not a mirror: it is there to orient you, not to flatter you.
From checklist to map 🧭
The trick is to look for the property before the category: authorization, identity, provenance, configuration, telemetry. Then observe how it fails in the domain. That is how you discover that access control recurs across APIs, clusters, and agents, but requires different tests and different controls. The category is the surface; the property is the concept; the mechanism is the domain.
It is the distance between those who ask “which list should I follow?” and those who ask “what trust decisions is this component making?”. The first question produces a document to hang on the wall; the second produces a threat model, and threat models — so they say — make the fortune of those who update them and the misfortune of those who print and frame them.
Security that reads well is security that never needed a meeting to be understood.
The guide The OWASP ecosystem explains the main lenses; the unified taxonomy connects them without pretending they are identical. The real test for designers: take your system, choose the right hills to watch, and treat each list as a map in which the territory changes faster than the cartographers.