OWASP Top 10 History → The Four OWASP Lists → Why Classic OWASP Breaks for LLMs → OWASP LLM Top 10 2025
TL;DR
- OWASP LLM Top 10 vs OWASP Top 10: four separate lists, four separate attack surfaces — they share underlying failure classes but differ entirely in what the attacker actually does
- If your system has a web frontend: Web App Top 10 (2021) applies
- If your system exposes REST or GraphQL APIs: API Security Top 10 (2023) applies
- If your workloads run on Kubernetes or containers: Cloud-Native App Security Top 10 applies
- If your system includes an LLM component — even a third-party API call: LLM Top 10 (2025) applies
- A RAG-based chatbot deployed on Kubernetes behind an API gateway touches all four lists simultaneously — and the attack paths at each layer are different
OWASP Mapping: Orientation episode. This post maps all four OWASP lists to their respective attack surfaces. Subsequent episodes (EP05–EP14) cover each OWASP LLM Top 10 category in depth with Red/Detect/Defend structure.
The Big Picture
WHICH OWASP LIST APPLIES TO YOUR ARCHITECTURE?
Your system component Applicable OWASP List
──────────────────────────────────────────────────────
Web frontend / rendered HTML Web App Top 10 (2021)
└─ XSS, CSRF, clickjacking
└─ Broken auth, session mgmt
REST/GraphQL API endpoint API Security Top 10 (2023)
└─ BOLA/IDOR, mass assignment
└─ Excessive data exposure
└─ Unrestricted resource use
Container / Kubernetes workload Cloud-Native App Sec Top 10
└─ Misconfigured workloads (+ Purple Team series)
└─ Vulnerable images
└─ Runtime compromise
LLM / AI component LLM Applications Top 10 (2025)
└─ Prompt injection ← this series
└─ Model/data poisoning
└─ RAG attacks, agent risks
──────────────────────────────────────────────────────
A single RAG chatbot on K8s behind an API gateway
touches ALL FOUR LISTS at the same time.
If you are deploying an LLM in production, all four lists apply. The question is not which one to use — it’s which part of your system falls under which list, and whether your security coverage has gaps between them.
The Web App Top 10 (2021): The Baseline
The original list. Covers HTTP-layer attacks on applications that serve content or handle user sessions.
What it addresses: Cross-site scripting, SQL injection, broken session management, insecure design at the application layer, misconfigured servers, vulnerable dependencies, server-side request forgery.
What it does not address: How an API client authenticates without a user session. How a Kubernetes workload is compromised at runtime. How an LLM misinterprets user input as an instruction. The 2021 list is the floor — it’s the minimum security bar for anything web-facing.
Primary tool class: DAST (Dynamic Application Security Testing) — OWASP ZAP, Burp Suite. SAST for source-level issues.
When this applies to your LLM system: The web frontend that wraps your chatbot. The admin UI for your AI pipeline. Any HTTP-facing surface — even if the backend is entirely LLM-powered.
The API Security Top 10 (2023): The API Layer
REST and GraphQL introduced attack surfaces that the web app list missed. The API Security Top 10 was published in 2019 and updated in 2023 precisely because API-specific attacks were not adequately covered.
Top categories:
– API1: Broken Object Level Authorization (BOLA/IDOR) — the most prevalent API vulnerability; accessing other users’ resources by changing an ID in the request
– API3: Broken Object Property Level Authorization — returning or accepting more data than the authenticated principal should see (replaces “Excessive Data Exposure” from 2019)
– API4: Unrestricted Resource Consumption — rate limiting gaps that enable abuse or DoS via API
– API6: Unrestricted Access to Sensitive Business Flows — no concept of “business logic” in the web app list; APIs expose workflows directly
What it does not address: Model-level behavior. Training-time attacks. Natural language injection. The API Security list treats the model as a black box behind an endpoint.
Why it matters for LLM systems: Your LLM is almost certainly accessed via an API — either a first-party API you built or a third-party API (OpenAI, Anthropic, Bedrock) you call. The API Security list covers that integration layer. An attacker who exploits BOLA against your API doesn’t need to understand prompt injection — they just need to change a user ID in the request.
The Cloud-Native App Security Top 10: The Infrastructure Layer
Containers, Kubernetes, microservices, and cloud-managed services introduced an orchestration layer that neither the web app list nor the API list covered.
Scope: Insecure workload configurations, insufficient network segmentation between microservices, vulnerable or unverified container images, over-permissioned service accounts, exposed cluster management interfaces.
What it does not address: What runs inside the container. If that container runs an LLM, the model’s behavior — prompt injection, system prompt leakage, RAG poisoning — is outside the cloud-native list’s scope.
Why it matters for LLM systems: LLM inference runs on infrastructure. If the pod running your model inference has an over-permissioned service account, an attacker who exploits the model doesn’t need to do anything sophisticated — they can use the pod’s IAM permissions to move laterally. The LLM is the initial access vector; the cloud-native misconfig is the blast radius.
For depth on cloud-native OWASP mapping, see OWASP Top 10 mapped to cloud infrastructure in the Purple Team series. This episode covers the concept; that series covers the attack paths.
The LLM Applications Top 10 (2025): The Model Layer
The attack surface that exists because of the model — not at the web layer, not at the API layer, not at the infrastructure layer, but in the probabilistic behavior of the language model itself and the systems it connects to.
The 10 categories:
| # | Category | What It Covers |
|---|---|---|
| LLM01 | Prompt Injection | Attacker input hijacks model behavior — direct or via retrieved content |
| LLM02 | Sensitive Information Disclosure | Model leaks training data, PII, API keys, system prompts via output |
| LLM03 | Supply Chain | Compromised model weights, plugins, datasets, or fine-tuning pipelines |
| LLM04 | Data and Model Poisoning | Training or fine-tuning data manipulated to introduce backdoors |
| LLM05 | Improper Output Handling | Downstream systems consume model output without validation |
| LLM06 | Excessive Agency | Autonomous agent tools not scoped to least capability |
| LLM07 | System Prompt Leakage | Extraction of hidden system prompt instructions |
| LLM08 | Vector and Embedding Weaknesses | RAG vector store poisoning or access control gaps |
| LLM09 | Misinformation | Model generates false information presented as fact |
| LLM10 | Unbounded Consumption | Uncontrolled token, compute, or API cost consumption |
What this list does not cover: The API through which you call the model (that’s the API Security list). The Kubernetes workload running the inference server (that’s the cloud-native list). The web UI that wraps the chatbot (that’s the web app list). The LLM Top 10 is specifically the model-layer attack surface.
Injection Across All Four Lists: A Comparison
“Injection” appears in all four lists. The word is the same. The attack is completely different.
| List | Category | Injection Type | Defense |
|---|---|---|---|
| Web App | A03 Injection | SQL, OS commands, LDAP — structured language injected via HTTP input | Parameterized queries, input validation, prepared statements |
| API Security | API8 Security Misconfiguration | Mass assignment / property injection — attacker sets fields that should not be writable | Input allowlisting, schema validation, explicit field binding |
| Cloud-Native | C4 Insecure Workload Config | Environment variable / config injection — attacker controls what gets injected into container at start | Immutable config, sealed secrets, workload admission control |
| LLM Applications | LLM01 Prompt Injection | Natural language injected into model context — attacker controls what the model interprets as instruction | No structural equivalent; requires guardrails, intent classification, output scanning |
The web app defense (parameterized queries) works because you can structurally separate data from code. SQL parsers don’t execute string literals as SQL commands. The LLM defense is fundamentally different because the model has no structural boundary between “user data” and “instruction.” Natural language IS the programming language. This is why LLM01 remains the most exploited category and the most difficult to remediate — not because engineers aren’t trying, but because the separation that makes SQL injection solvable doesn’t exist in natural language processing.
Architecture Coverage Map: RAG Chatbot on Kubernetes
Take a concrete system: a customer-facing RAG chatbot deployed on Kubernetes, calling an external LLM API, indexing internal documents in a vector database, with a React frontend and a FastAPI backend.
ATTACK SURFACE MAP
React Frontend ← Web App Top 10
└─ XSS, CSRF, clickjacking
└─ Broken auth (session management)
FastAPI Backend (REST) ← API Security Top 10
└─ BOLA: can user A retrieve user B's documents?
└─ Excessive data exposure in API responses
└─ Rate limiting on LLM API calls
Kubernetes Cluster ← Cloud-Native Top 10
└─ Service account permissions on vector DB pod
└─ Container image vulnerabilities
└─ Network policy: can inference pod call anything?
LLM Component ← LLM Applications Top 10
└─ Prompt injection via user input (LLM01)
└─ System prompt leakage (LLM07)
└─ Vector DB poisoning via document upload (LLM08)
└─ Agent over-permission on retrieval tools (LLM06)
└─ Sensitive data in indexed documents leaks (LLM02)
GAPS (attack paths that cross list boundaries):
Injected prompt → agent calls API endpoint → BOLA
Compromised K8s service account → access vector DB → LLM08
XSS on frontend → steal session → BOLA on document retrieval
The most dangerous attack paths cross list boundaries. An attacker who injects a prompt (LLM01) that causes an agent to call an API endpoint (API Security Top 10) that has a BOLA vulnerability is exploiting two separate OWASP lists in a single attack chain. Security reviews that only audit against one list miss these compound paths.
⚠ Production Gotchas
Auditing against one list and calling it done
Security teams often run DAST against the web layer and consider the application “OWASP covered.” If the application includes an LLM component, a vector database, and a Kubernetes deployment, the DAST scan covered at most 25% of the attack surface. Multi-list auditing is not a luxury — it’s the correct scope.
Assuming the LLM provider handles LLM security
OpenAI, Anthropic, AWS Bedrock — these providers harden their infrastructure. They do not control how you construct prompts, what you put in your system prompt, how you scope your agent’s tool access, or what you index in your vector store. LLM01 through LLM10 are almost entirely in your application’s scope, not the provider’s.
Treating RAG retrieval as a read-only, safe operation
Retrieval augmented generation adds a retrieval step that fetches content from a vector database to augment the model’s context. That retrieved content is trusted by the model — it treats it as authoritative context, not as potentially hostile user input. If an attacker can control what gets indexed (document upload, web crawl), they can inject instructions into retrieved content that the model will execute. This is LLM08 (Vector/Embedding Weaknesses) combined with LLM01 (indirect prompt injection). It is one of the most exploited compound paths in production LLM systems today.
Quick Reference: Four-List Matrix
| Web App (2021) | API Security (2023) | Cloud-Native | LLM Apps (2025) | |
|---|---|---|---|---|
| Surface | HTTP/rendered UI | REST/GraphQL endpoints | K8s/containers | Model behavior, RAG, agents |
| Primary attacker | Browser/web client | API consumer | Cluster access | LLM user/document uploader |
| Top risk | Broken access control | BOLA/IDOR | Misconfigured workloads | Prompt injection |
| Key defense | Input validation, RBAC | Object-level authz | Admission control, network policy | Guardrails, output scanning |
| Primary test tool | OWASP ZAP / Burp | Postman + custom scripts | Trivy, Checkov, kube-bench | Garak, PyRIT, Promptfoo |
| Compliance tie-in | PCI DSS, HIPAA | API gateway policies | CIS K8s Benchmark | NIST AI RMF, ISO 42001, EU AI Act |
Framework Alignment
| Framework | Relevant Requirement | Connection |
|---|---|---|
| NIST AI RMF | MAP 1.5 (identify applicable risk categories) | Use all four lists to scope the risk surface before mapping to NIST categories |
| ISO 27001:2022 | A.8.25 (secure development lifecycle) | Multi-list OWASP coverage maps directly to application security requirements across the SDLC |
| SOC 2 | CC6.1 (logical access controls) | BOLA (API list) and broken access control (web app list) are the primary controls relevant to SOC 2 evidence |
| EU AI Act | Art. 9 (risk management) | High-risk AI system assessments must address model-layer risks (LLM list) in addition to infrastructure-layer controls |
Key Takeaways
- Four OWASP lists exist in 2025; which one applies depends on which component of your architecture you are assessing — most production LLM systems are in scope for all four
- The word “injection” appears in all four lists; the technique and the defense are completely different in each
- RAG-based applications are particularly exposed to compound attack paths that cross list boundaries — a single exploit chain can touch LLM01, LLM08, and API BOLA in sequence
- Security reviews scoped to one OWASP list on a multi-layer system leave architectural gaps; the attack paths that matter often run between the lists
- LLM providers handle model infrastructure security; your application’s scope includes everything from how you construct prompts to what you put in the vector store
What’s Next
The next episode is the bridge. Four lists exist, but the LLM list is not just “web app security applied to models.” The three classic OWASP assumptions — deterministic behavior, parseable input, enumerable permissions — break down entirely when the application is a language model. Understanding why changes how you approach everything in Parts II and III.
Why Classic OWASP Breaks Down for LLMs: The New Attack Surface →
Get EP03 in your inbox when it publishes → subscribe