Skip to content

L2.4.1 — OWASP LLM Top 10: overview and how it differs from web-app Top 10

Type: Theory · Duration: ~4 min · Status: Mandatory Module: Module 2 — AI Security Foundations Framework tags: OWASP Top 10 for LLM Applications (introduction)

Learning objectives

  1. State the purpose of the OWASP LLM Top 10 and recall its 10 entries by name.
  2. Identify two structural differences from the classical OWASP Top 10 for web apps.

Core content

The OWASP Top 10 for Large Language Model Applications is a community-curated list of the highest-impact vulnerability classes in LLM-powered systems. First released in 2023, regularly updated. The current version (2025) lists:

LLM01  Prompt Injection
LLM02  Insecure Output Handling
LLM03  Training Data Poisoning
LLM04  Model Denial of Service
LLM05  Supply Chain Vulnerabilities
LLM06  Sensitive Information Disclosure
LLM07  System Prompt Leakage             (formerly sub-case of LLM06)
LLM08  Excessive Agency
LLM09  Overreliance
LLM10  Model Theft

(Entry numbering and exact titles drift between releases — always check the current OWASP page when citing.)

How it differs from the classical web-app Top 10

Two structural differences worth knowing.

The threats span multiple system layers, not just the application code. Classical OWASP Top 10 entries (SQL injection, XSS, CSRF) all live in your application code. Most LLM Top 10 entries span code and model and data, often spanning the vendor boundary. Training Data Poisoning isn't your code bug; Supply Chain Vulnerabilities aren't your code bug; Model Theft isn't your code bug. The list is honest about this — but it means your defensive plan can't be "fix our code." It has to be "fix our code and select better vendors and operate the deployment carefully."

The entries are about model behavior, not protocol abuse. Classical OWASP entries are mostly about violating the intended contract of a protocol or interface (HTTP, SQL, the DOM). LLM Top 10 entries are mostly about the model being induced to do something the deployer didn't want — a fundamentally different shape, because there is no "intended contract" of the model output the way there is for an HTTP response. Defending these requires statistical thinking (evals, sampling, distribution drift) more than the binary thinking classical AppSec optimizes for.

When to reach for OWASP LLM Top 10

  • Pre-launch security review. Walk the list against your LLM feature. If you can't show coverage for each entry, you have a list of items to address before launch.
  • Audit and compliance conversations. "We have controls for all ten" is a defensible statement; "we have controls for each entry, here they are" is better.
  • Onboarding new engineers. It's the fastest way to give a new hire a vocabulary for LLM-specific risk.

It is not a comprehensive threat model. Many real attacks chain entries together or live in gaps between them. For that, you reach for ATLAS and your own DFD-driven threat modeling.

Real-world example

When OWASP first published the list in 2023, vendors who had deployed LLM features started using it as a procurement checklist for their AI subprocessors. By late 2024, customer security questionnaires routinely included "Which OWASP LLM Top 10 entries does your product address?" as a question. The list became the de-facto shared language between buyer and seller, much as the classical Top 10 did between AppSec and procurement in the late 2000s. Whether you like that or not, it's the trajectory.

Key terms

  • Top-10 list — a community-curated, periodically-revised list of high-impact risks.
  • Procurement checklist — buyer-side question template; the LLM Top 10 is now a default item.

References

  • OWASP Top 10 for LLM Applications — https://owasp.org/www-project-top-10-for-large-language-model-applications/
  • OWASP "About" page — community process & contributors — https://owasp.org/www-project-top-10-for-large-language-model-applications/about/

Quiz items

  1. Q: Name three OWASP LLM Top 10 entries from memory. A: Any three of LLM01–LLM10 with correct names.
  2. Q: Why can't a defender treat the OWASP LLM Top 10 as a "fix our code" checklist the way they could treat the classical Top 10? A: Because LLM Top 10 entries span code, model, and data, often crossing the vendor boundary; some require vendor selection and operational controls, not code changes.

Video script (~520 words, ~3.5 min)

[SLIDE 1 — Title]

OWASP Top 10 for LLMs. Four minutes. By the end you'll recall the ten entries and know how this list differs structurally from the classical Top 10.

[SLIDE 2 — The ten entries]

Here are the ten. LLM01: Prompt Injection. LLM02: Insecure Output Handling. LLM03: Training Data Poisoning. LLM04: Model Denial of Service. LLM05: Supply Chain Vulnerabilities. LLM06: Sensitive Information Disclosure. LLM07: System Prompt Leakage. LLM08: Excessive Agency. LLM09: Overreliance. LLM10: Model Theft.

Entry numbering and exact titles drift between releases. Always check the current OWASP page when you cite a specific entry in a report. The shape is stable; the wording shifts.

[SLIDE 3 — Two structural differences from classical Top 10]

Two structural differences from the web-app Top 10 you already know. First: the threats span multiple system layers, not just application code. Classical Top 10 entries — SQL injection, XSS, CSRF — all live in your code. Most LLM Top 10 entries span code and model and data, often crossing the vendor boundary. Training Data Poisoning isn't your code bug. Supply Chain isn't your code bug. Model Theft isn't your code bug. Your defensive plan can't be "fix our code." It has to be "fix our code and select better vendors and operate the deployment carefully."

[SLIDE 4 — Difference two]

Second difference: the entries are about model behavior, not protocol abuse. Classical entries are mostly about violating the intended contract of a protocol or interface — HTTP, SQL, the DOM. LLM entries are mostly about the model being induced to do something the deployer didn't want. Fundamentally different shape, because there's no "intended contract" of the model output the way there is for an HTTP response. Defending these requires statistical thinking — evals, sampling, distribution drift — more than the binary thinking classical AppSec optimizes for.

[SLIDE 5 — When to reach for it]

When to reach for the OWASP LLM Top 10. Pre-launch security review — walk the list against your feature, if you can't show coverage for each entry, you have a list of items to address. Audit and compliance — "we have controls for all ten" is defensible. Onboarding new engineers — it's the fastest way to hand someone a vocabulary for LLM-specific risk. It is not a comprehensive threat model. Real attacks chain entries together. For that, you reach for ATLAS and your own DFD-driven threat modeling.

[SLIDE 6 — Where it's headed]

One trajectory note. By late 2024, customer security questionnaires routinely included "Which OWASP LLM Top 10 entries does your product address?" as a default question. The list became the shared procurement language between buyer and seller, much as the classical Top 10 did between AppSec and procurement in the late 2000s. Whether you like that or not, that's where it is.

[SLIDE 7 — Up next]

Next three lessons walk the entries in detail. Three groupings of three to four. See you there.

Slide outline

  1. Title — "OWASP LLM Top 10: overview".
  2. The ten entries — single full-screen list LLM01–LLM10 with names.
  3. Difference one — three planes diagram (code · model · data) with classical Top 10 in code only, LLM Top 10 spanning all three.
  4. Difference two — left: classical Top 10 entry as a "binary" defense (HTTP response valid/invalid); right: LLM Top 10 entry as a statistical defense (distribution shift, sample rate).
  5. When to reach for it — three use-cases as cards: pre-launch review · audit · onboarding.
  6. Where it's headed — quote from a hypothetical security questionnaire: "Which OWASP LLM Top 10 entries does your product address?"
  7. Up next — "L2.4.2 — LLM01–LLM03 in detail, ~5 min."

Production notes

  • Recording: ~3.5 min. Cap 5.
  • Re-check entry titles against the current OWASP page before each recording (titles have drifted 2023 → 2025; expect further drift).