series: OWASP LLM Top 10: From Web Roots to AI Frontiers
episode: 1 of 22
status: Draft
slug: /owasp-top-10-history-evolution/
focus_keyphrase: OWASP Top 10 history evolution
search_intent: Informational
meta_description: “OWASP Top 10 history: how the list evolved from SQL injection in 2003 to LLM prompt injection in 2025 — and what stayed constant across every version.”
owasp_mapping: “Foundation episode — establishes the OWASP organization, methodology, and six-version evolution before branching to the four lists that exist today (Web App, API, Cloud-Native, LLM).”
OWASP Top 10 History → The Four OWASP Lists → Why Classic OWASP Breaks for LLMs → OWASP LLM Top 10 2025
TL;DR
- OWASP Top 10 history evolution spans six published versions from 2003 to 2021 — the category names change every cycle; the underlying failure classes do not
- Injection, broken authentication, and access control have appeared in every single version under different names; they were exploited in 2003 and they are still the top breach vectors in 2025
- The 2021 edition abstracted away from web-app-specific language into attack classes — which is what made OWASP applicable to cloud infrastructure, APIs, Kubernetes, and ultimately AI systems
- OWASP is not a compliance standard; it is a community consensus on risk — but in 2025, the EU AI Act began directly citing the OWASP AI Exchange, which changes that calculus
- Four distinct OWASP Top 10 lists exist today: Web App (2021), API Security (2023), Cloud-Native App Security, and LLM Applications (2025) — this series covers the last one, built on the foundation of the first
OWASP Mapping: Foundation episode. No single OWASP LLM category. This episode traces the lineage from OWASP Top 10 (2003) through all six web app versions to the four lists that exist in 2025. Every subsequent episode maps directly to one or more OWASP LLM Top 10 (2025) categories.
The Big Picture
OWASP TOP 10 EVOLUTION: 2003 → 2025
2003 ──▶ Web-era injection (SQL, XSS, parameter tampering)
│ HTTP/1.0 apps. Databases directly exposed via
│ dynamic SQL. Sessions via URL parameters.
│
2007 ──▶ Session management + insecure comms elevated
│ HTTPS adoption slow. Cookie theft common.
│
2010 ──▶ Unvalidated redirects added. XSS re-ranked.
│ The list reflects what's being actively exploited.
│
2013 ──▶ CSRF dropped. Missing Function-Level Access added.
│ First signs of API/microservice thinking.
│
2017 ──▶ Risk-weighted ranking. CWE mappings. XXE added.
│ Insecure Deserialization, Logging failures enter.
│ The list becomes infrastructure-aware.
│
2021 ──▶ Abstracted to attack classes. Insecure Design +
│ SSRF added. Infrastructure/cloud applicability.
│ ┌──────────────────────────────┐
│ │ Now maps to cloud infra │ ← Purple Team EP02
│ │ Kubernetes, APIs, pipelines │
│ └──────────────────────────────┘
│
├──▶ API Security Top 10 (2023)
│ REST/GraphQL-specific risks
│
├──▶ Cloud-Native App Security Top 10
│ Containers, orchestration
│
└──▶ LLM Applications Top 10 (2023 v1 → 2025 v2)
Prompt injection, model poisoning, RAG attacks
← THIS SERIES
OWASP Top 10 history is not a list of bugs. It is a snapshot of where the application surface was — and where attackers found the seams — taken every three to four years.
The 2003 Founding: What the Web Looked Like
The OWASP Foundation was established in 2001. The first Top 10 list shipped in 2003.
The web in 2003 looked nothing like it does now. Applications were monolithic. Databases were directly queried via dynamic SQL strings concatenated from user input. Authentication was session cookies stored in URL parameters. “Security” was a firewall at the network perimeter — if you were inside the network, you were trusted.
SQL injection was not a theoretical risk. It was how attackers exfiltrated data in bulk, every day, at scale. The same for XSS: inject JavaScript into a page, steal session cookies, impersonate users. These were not edge cases — they were the primary breach vectors because the web was built without any assumption that input was untrusted.
The OWASP founding premise: developers build these vulnerabilities not because they are negligent, but because the threat model was never taught. The Top 10 list was documentation, not enforcement — a shared vocabulary for what actually causes breaches.
Version-by-Version: What Changed and What Did Not
| Year | Most Significant Addition | What Dropped / Changed | What It Reflects |
|---|---|---|---|
| 2003 | Unvalidated Input, SQL Injection, XSS, Command Injection | — | Dynamic SQL era; input treated as trusted |
| 2007 | CSRF, Insecure Comms, Improper Error Handling | Unvalidated Input consolidated | HTTPS adoption gap; session theft via network |
| 2010 | Unvalidated Redirects + Forwards | CSRF de-emphasized | Open redirectors weaponized for phishing |
| 2013 | CSRF dropped; Missing Function-Level Access | Insecure Storage removed | API-style thinking entering the list |
| 2017 | Insecure Deserialization, Logging + Monitoring Failures, XXE | Unvalidated Redirects dropped | Server-side attack complexity; blind spots in detection |
| 2021 | Insecure Design (new class), SSRF | XSS merged under Injection | Architecture-level risk; abstract attack classes introduced |
The column that doesn’t change: Broken Access Control, Injection, and Authentication Failures have appeared in every version. The names shift (A01 becomes A07 becomes A01 again). The category descriptions evolve. The underlying failure — you can access things you shouldn’t, or execute code you shouldn’t, or authenticate as someone you’re not — never leaves the list.
This is the most important observation in the entire series: OWASP’s vocabulary modernizes; the failure classes are constants. When you see LLM01 Prompt Injection in the 2025 LLM list, you are looking at the same failure class as A03 Injection in the web app list. The attack surface changed. The category did not.
What the 2021 Abstraction Unlocked
The 2017 → 2021 transition was architecturally significant. Prior versions were implicitly scoped to HTTP requests against web applications. The 2021 list made a deliberate choice to describe attack classes rather than attack techniques.
“Injection” in 2021 means: untrusted data is sent to an interpreter and executed as code or commands. That definition covers SQL injection, LDAP injection, OS command injection — and, it turns out, natural language prompt injection in LLMs. The definition doesn’t care what the interpreter is.
“Broken Access Control” in 2021 means: a principal can act on a resource or perform an action it was not intended to. That covers misconfigured S3 buckets, Kubernetes RBAC gaps — and an LLM agent with tool access that hasn’t been scoped to least capability.
This abstraction is why OWASP became applicable to cloud infrastructure, APIs, containers, and AI. It’s also why the Purple Team series (specifically EP02) was able to map the entire 2021 list directly to cloud infrastructure attack paths — and why this series can map the same abstraction to LLM attack surfaces.
For the cloud infrastructure angle, see OWASP Top 10 mapped to cloud infrastructure. This series starts where that one ends: the attack surface that cloud infrastructure runs on is increasingly powered by language models.
The Four Lists That Exist Today
OWASP has expanded beyond the original web app list. Four Top 10 lists are actively maintained as of 2025:
OWASP Top 10 — Web Application Security Risks (2021)
The original. HTTP-layer attacks on server-rendered or API-backed apps. A01 Broken Access Control through A10 SSRF. Still the baseline for any web-facing application.
OWASP API Security Top 10 (2023)
REST and GraphQL-specific. Broken Object Level Authorization (BOLA/IDOR), excessive data exposure, mass assignment, unrestricted resource consumption. API attacks account for the majority of cloud breaches — this list exists because the web app list missed API-specific attack surfaces.
OWASP Cloud-Native Application Security Top 10
Kubernetes, containers, orchestration-layer risks: insecure workload configurations, misconfigured cloud storage, vulnerable container images, runtime compromise. The cloud-infra angle.
OWASP Top 10 for LLM Applications (2025)
The list this series is built on. Prompt injection, model poisoning, supply chain risks for model artifacts, RAG database attacks, autonomous agent over-permission. The attack surfaces that arrive when you embed a language model in your infrastructure.
The full comparison — which list applies to which part of your architecture, and how they overlap — is in the next episode.
Why AI Arrived at OWASP
The OWASP Top 10 for LLM Applications was not invented top-down. It came from practitioners who were deploying language models and cataloguing the breach patterns they were seeing.
The first version (v1.0) shipped in August 2023, driven by a working group that formed in May 2023 — roughly six months after ChatGPT created widespread LLM deployment. The timeline matters: security researchers were finding real vulnerabilities in production systems in real time, and the OWASP list was the community’s way of documenting the emerging threat model before it became a liability.
Version 2.0 shipped in November 2024. Two entirely new categories — System Prompt Leakage (LLM07) and Vector/Embedding Weaknesses (LLM08) — were added because RAG-based applications and agentic AI had become prevalent enough that their specific attack surfaces warranted dedicated treatment. Sensitive Information Disclosure moved from #6 to #2 because real breach data, not theory, showed it was the second most commonly exploited category.
The OWASP AI Exchange — a parallel OWASP project — went further. It produced a 300-page technical guide on AI security and privacy and contributed directly to the EU AI Act’s technical requirements. As of 2025, the EU AI Act for high-risk AI systems references risk assessment requirements that align directly with OWASP LLM Top 10 categories. OWASP is still not a compliance standard. But for AI systems in the EU, ignoring it is no longer a neutral choice.
⚠ Production Gotchas
“OWASP is a checklist you run once”
It’s a living document updated every 3–4 years based on actual breach data. The 2021 web app list is not the same document as the 2017 list. The 2025 LLM list has different categories than the 2023 v1 list. Running the 2017 checklist on a 2025 system is not OWASP compliance — it is a false sense of coverage.
“We are OWASP compliant”
OWASP is not a compliance standard. There is no OWASP certification, no OWASP audit, no OWASP controls framework. Organizations that say “we are OWASP compliant” mean they have reviewed the list and addressed the categories — that is a risk reduction exercise, not a regulatory state. The EU AI Act is a compliance standard. NIST AI RMF is a compliance framework. OWASP is the technical operationalization of both.
“The LLM Top 10 only matters if you’re building LLMs”
You don’t need to build LLMs for the list to apply. If you are deploying a chatbot powered by a third-party API, using an AI coding assistant that has access to your codebase, or running a RAG application that indexes internal documents — you are within scope of LLM01 through LLM10. The attack surface is the integration, not the model itself.
Quick Reference: OWASP Top 10 Versions
| Year | Version | Key Additions | Key Removals | Architectural Context |
|---|---|---|---|---|
| 2003 | v1.0 | Injection, Broken Auth, XSS, Insecure Config | — | Monolithic web apps, dynamic SQL |
| 2007 | v2.0 | CSRF, Insecure Comms | Unvalidated Input → merged | HTTPS gap, session theft |
| 2010 | v3.0 | Unvalidated Redirects | — | Phishing via redirectors |
| 2013 | v4.0 | Missing Function-Level Access | CSRF moved to lower priority | API patterns emerging |
| 2017 | v5.0 | XXE, Insecure Deserialization, Logging Failures | Unvalidated Redirects | Microservices, detection gaps |
| 2021 | v6.0 | Insecure Design, SSRF | XSS merged into Injection | Attack class abstraction; cloud/AI applicability |
Current parallel lists:
| List | Last Updated | Primary Surface | Key Org |
|---|---|---|---|
| Web App Top 10 | 2021 | HTTP/web apps | OWASP |
| API Security Top 10 | 2023 | REST/GraphQL APIs | OWASP |
| Cloud-Native App Security Top 10 | 2022 | K8s/containers | OWASP |
| LLM Applications Top 10 | 2025 (v2.0) | Language models/AI | OWASP GenAI |
Framework Alignment
| Framework | Relevant Function | Connection to OWASP History |
|---|---|---|
| NIST CSF 2.0 | IDENTIFY (ID.RA) | OWASP is the community risk catalog that feeds asset risk assessments |
| ISO 27001:2022 | A.8.8 (vulnerability management) | OWASP Top 10 is the standard reference for vulnerability class coverage |
| NIST AI RMF | MAP 1.5 | Identify which risk categories from OWASP LLM Top 10 apply to specific system components |
| EU AI Act | Art. 9 (risk management system) | High-risk AI system risk assessments reference OWASP AI Exchange technical guidance |
Key Takeaways
- OWASP Top 10 history is the story of attack surfaces expanding — web to API to cloud to AI — with the same failure classes appearing at each layer
- The 2021 abstraction to attack classes (not web-specific techniques) was the architectural decision that made OWASP applicable everywhere, including LLMs
- Four lists exist today; real systems touch multiple lists simultaneously
- The LLM Top 10 (v2.0, 2025) is not theoretical — it was built from documented production breach patterns, and v2.0 added new categories because RAG and agentic AI created new attack surfaces fast enough to warrant them
- OWASP is a risk framework, not a compliance standard — until 2025, when the EU AI Act began referencing OWASP AI Exchange guidance for high-risk AI systems
What’s Next
EP02 answers the navigation question this episode raises: if four OWASP lists exist, which one applies to your system — and what happens when a single architecture touches all four at once?
The Four OWASP Lists: Web App, API, Cloud-Native, and LLM Compared →
Get EP02 in your inbox when it publishes → subscribe