OWASP Top 10 for LLM Applications (2025): A Developer's Field Guide

The OWASP Top 10 for Large Language Model Applications has become the canonical reference for application security teams trying to make sense of LLM-integrated systems. The 2025 edition — released at the end of 2024 as the successor to the original 2023 list — is the version most procurement security questionnaires, internal threat-modeling templates, and AppSec program documents now reference. This post walks the ten risks in the 2025 list from a developer's perspective: what each risk actually means at the level of code, where the 2025 list differs from the 2023 version, what defenses work in practice, and how the LLM Top 10 fits into the broader application security verification work captured in the OWASP ASVS 5.0 guide and the OWASP Top 10 2025 web application list. For the deep dive on prompt injection specifically — the LLM Top 10's #1 risk — see the prompt injection developer guide, which goes well beyond what this overview can cover in a single section.

Why the LLM Top 10 Exists and How It Differs From the Web Top 10

The original OWASP Top 10 was created in 2003 to focus a fragmented application security conversation on the small set of risks that account for most real-world web application breaches. The LLM Top 10 was created in 2023 for the same reason in a different domain — to give application security teams trying to harden LLM-integrated systems a shared vocabulary for the risks that actually matter, rather than the much larger and rapidly evolving set of academic concerns being discussed in the ML safety research community. The two Top 10 lists are complementary; an application that integrates an LLM has both web application and LLM-specific attack surfaces, and the verification effort needs to cover both.

The structural difference between the two lists is that the web Top 10 has roughly stabilized — the same risk categories have appeared with minor rearrangement across the 2017, 2021, and 2025 editions, because the underlying vulnerability classes (injection, broken access control, cryptographic failures) are well-understood and relatively stable. The LLM Top 10 has shifted substantially between the 2023 and 2025 editions, because the underlying technology and threat landscape have shifted substantially. Prompt injection was already the #1 risk in 2023 and remains #1 in 2025, but four of the ten risk categories changed names or scope between the two editions, and three are effectively new.

The practical implication is that a team running an LLM application security program against the 2023 list is overdue for an update. The defenses that worked in 2023 are largely still valid; the additions in 2025 reflect risks that have become significantly more important — particularly around vector store security, system prompt leakage, and unbounded resource consumption — as production LLM deployments have matured beyond the experimental phase of 2023. The owasp top 10 for llm applications 2023 release is preserved in the OWASP project's release archive for reference, and teams maintaining ASVS-aligned verification programs that originally referenced the 2023 list need to migrate their evidence collection to the 2025 IDs the same way ASVS 4.0.3 programs migrated to 5.0.0 IDs.

The 2023 → 2025 Evolution at a Glance

The Ten Risks — Section by Section

LLM01 — Prompt Injection

Prompt injection remains the dominant LLM application risk, and the 2025 edition expands the category to explicitly include multimodal injection (image-based, audio-based, file-based prompts) alongside the text-based injection that dominated 2023's discussion. The mechanism is the same across modalities — instructions injected into the model's input context override or subvert the application's intended behavior — and the defenses are also broadly the same: input/output mediation, system prompt hardening, sandboxing of agentic capabilities, and runtime monitoring for anomalous model behavior.

Direct prompt injection ("ignore previous instructions and...") is the canonical case. Indirect prompt injection — where attacker-controlled content reaches the LLM via documents, web pages, emails, or other indirect channels — is the variant that has produced most real-world incidents in 2025-2026, because the attacker does not need access to the application's direct interface; they only need to influence content that the application processes. An LLM-powered support agent that summarizes incoming tickets is vulnerable to a ticket containing instructions designed to alter the agent's response to other users. A code review assistant that processes pull request diffs is vulnerable to instructions embedded in those diffs.

The prompt injection developer guide covers the full taxonomy — 10 attack categories, 12 static defenses, red-team methodology — at the depth a developer building defenses against this class needs. The summary for the LLM Top 10 framing is that prompt injection should be treated as the LLM equivalent of injection in the web Top 10: a category where defense-in-depth across input, processing, and output stages is the standard, no single defense is sufficient, and the verification effort warrants substantial investment. For developers searching for prompt injection cyberattack definition techniques prevention as a single learning objective — the canonical phrasing of the topic in incident reports and academic literature — the LLM01 category sits at the intersection of those three concerns: the definition (what makes an input a prompt injection rather than benign content), the techniques (the ten attack categories the deep dive enumerates), and the prevention (the 12 static defenses plus the runtime monitoring patterns).

LLM02 — Sensitive Information Disclosure

LLMs leak sensitive information in three operationally distinct ways. They reveal training-data memorization (verbatim or near-verbatim reproduction of training examples that contained sensitive content). They reveal context-window contents (system prompts, retrieved documents, conversation history) when prompted in ways that bypass output filtering. And they reveal indirect signals (membership inference, attribute inference) about training data or context that allow an attacker to learn things the model was not asked directly.

The defenses cluster around data hygiene at training time, context-window isolation at inference time, and output mediation between the model and the user. Training data should be sanitized for personal data, secrets, and proprietary content before the model sees it. Context windows should be scoped to the specific user and request, with retrieved documents tagged with access control metadata that prevents the model from being given content the user is not authorized to see. Output should be filtered for known sensitive patterns (credit card numbers, secrets, internal URLs) before being returned to the user.

The class of bug most often associated with this category is overshared context — a RAG system that retrieves documents based on semantic similarity without filtering by the user's authorization, allowing an attacker to phrase queries that retrieve documents intended for other users. The fix is to enforce access control at the retrieval step, not just at the original document store level: the vector store query should include the user's authorization context as a filter, not retrieve all documents and post-filter.

LLM03 — Supply Chain

Supply chain risk in LLM applications spans three categories of dependency that traditional software supply chain security does not cover well. Model dependencies — the foundation models the application calls, whether hosted by OpenAI, Anthropic, Google, or self-hosted from Hugging Face — have provenance, integrity, and version-stability concerns analogous to but distinct from package dependencies. Training data dependencies — the datasets used for fine-tuning, evaluation, and reinforcement learning — have integrity and license concerns that need to be tracked alongside code dependencies. Plugin and tool dependencies — the external tools that agentic LLM applications can invoke — extend the attack surface to whatever the plugin can do on the application's behalf.

The defenses extend traditional software composition analysis patterns. Model and dataset provenance should be tracked with the same rigor as package dependencies — pinned versions, signed artifacts where available, automated vulnerability monitoring for known-bad model versions. Plugins should be reviewed and sandboxed; an LLM with access to a plugin that can read arbitrary files is effectively granting attackers (via prompt injection) the same access. The emerging tooling for ML supply chain (Sigstore for model signing, ML BOM formats analogous to SBOM, model registries with provenance attestation) is still maturing as of mid-2026 but is the direction the discipline is heading.

LLM04 — Data and Model Poisoning

Data and model poisoning attacks insert malicious content into the data that trains, fine-tunes, or augments the model, with the intent of producing behavior the attacker controls. Training-time poisoning requires access to the training pipeline and is generally limited to insider or supply-chain scenarios. Fine-tuning poisoning is more accessible — many production LLM applications fine-tune on user feedback or organization-specific data, and poisoning that feedback channel can systematically bias the model. Inference-time poisoning via RAG — the LLM08 category in the 2025 list — has its own dedicated section because the attack surface and defenses are sufficiently distinct.

The defenses are layered. Training-data validation — checking incoming data against expected distributions, deduplicating, filtering for known attack patterns — catches the easiest poisoning attempts. Model behavior testing — exercising the model with known test cases on every retrain to catch regressions in known-good behavior — catches subtler poisoning that changed model behavior in detectable ways. Provenance tracking — knowing which training examples contributed to which model versions — supports incident response when poisoning is suspected after the fact. The hard problem is targeted poisoning where the attacker has aligned their attack pattern with rare inputs the testing suite does not exercise; this remains an open research area as of 2026.

LLM05 — Improper Output Handling

LLM-generated output flowing back into application logic without sanitization is the LLM analog of treating user input as trusted. The model produces text; the application treats that text as commands, code, queries, or HTML. A model that generates SQL based on a natural-language query, with the SQL executed directly against the production database, has all the failure modes of classical SQL injection — exacerbated by the fact that the attacker can influence the SQL through the natural-language query without the application having any way to know the natural-language query was attacker-controlled.

The defense pattern is to treat LLM output as untrusted user input — apply the same output encoding, parameterization, sanitization, and validation that the application would apply to direct user input. An LLM that produces HTML output rendered to other users requires the same XSS prevention as user-generated HTML. An LLM that produces shell commands requires the same command-injection prevention as user-supplied shell commands. The boundary between "user input" and "LLM output" is operationally artificial — both should be treated as untrusted, both should be mediated by the same defensive layer.

The class of bug most often associated with this category is direct execution of generated content — the LLM produces code that the application runs, the LLM produces a database query that the application executes, the LLM produces a tool invocation that the application performs. The defenses are sandboxing (LLM-generated code runs in a restricted environment), explicit validation (LLM-generated SQL is parsed and validated against an allowlist of structures), and least-privilege execution (whatever the LLM can cause to be executed runs with the minimum privileges necessary).

LLM06 — Excessive Agency

Agency risk in LLM applications is the cluster of failures that arise when the application grants the LLM more capability than necessary. An LLM-powered customer service agent that has access to a "delete user account" tool can be prompt-injected into deleting a victim's account; an LLM-powered code review assistant that has access to a "merge pull request" capability can be prompt-injected into merging malicious code. The 2025 edition's framing of excessive agency explicitly addresses agentic LLM applications — the rapidly growing class of LLM systems that take autonomous action against external systems based on model reasoning rather than direct user instruction.

The defenses are scope, mediation, and confirmation. Scope: the LLM should have access to the minimum set of tools necessary for its intended function, with no "general purpose" tools that the attacker can chain into harmful actions. Mediation: tool invocations should be reviewable before execution, either by automatic policy checks (this tool, with these arguments, is allowed) or by human-in-the-loop confirmation for high-impact actions. Confirmation: actions with significant consequence should require explicit user confirmation through an out-of-band channel — the LLM cannot self-authorize its own confirmation.

The agentic AI case extends this discussion substantially; the agentic AI security guide covers the agent-specific risks, the OWASP Agentic AI Top 10, and the defensive patterns (AWS scoping matrix, Anthropic's browser-use mitigations, scope limitation patterns) that work in production agentic deployments.

LLM07 — System Prompt Leakage

System prompt leakage is new in the 2025 list, reflecting the operational reality that production LLM applications carry substantial intellectual property and security-sensitive content in their system prompts. The system prompt typically encodes the application's behavior — what it should and should not do, what tone to take, what factual constraints to honor, what tools to use under what conditions. Leaking the system prompt to an attacker exposes the application's defenses, allows the attacker to craft inputs that work around them, and in some cases exposes business logic that the application's owner intended to keep private.

The defenses cluster around two ideas: don't put secrets in system prompts (the system prompt should not contain API keys, internal credentials, or content that would be harmful if disclosed), and assume the system prompt will leak (the application's security posture should not depend on the system prompt remaining secret). The second principle is the deeper one — a system prompt is a defensive layer, not a secret. Designs that assume system prompt secrecy as a security property have a fragile defense; designs that assume the system prompt will eventually be disclosed and build their security around that assumption have a robust one.

LLM08 — Vector and Embedding Weaknesses

Vector store and embedding weaknesses are also new in the 2025 list, reflecting the dominance of retrieval-augmented generation (RAG) in production LLM applications. The vector store is the index against which user queries are matched to retrieve relevant context; the embeddings represent that content in a high-dimensional vector space. Both can be attacked: the vector store can be poisoned with attacker-influenced content, the embedding model can be exploited to produce embeddings that retrieve unintended content, and the retrieval step itself can leak information about the contents of the store.

The defenses are access control at retrieval, content validation at ingestion, and embedding-model selection from trusted sources. Access control at retrieval means the vector store query includes the user's authorization context as a filter, so an unprivileged user cannot retrieve documents they should not see even if the documents are semantically relevant to their query. Content validation at ingestion means content added to the vector store is reviewed (or filtered) for known attack patterns before being indexed. Embedding-model selection means the embedding model used to produce vectors comes from a trusted source — embedding model backdoors are an emerging research concern, and using a maintained model from a reputable source is the current best mitigation.

LLM09 — Misinformation

LLMs produce confident-sounding output that may be factually wrong, and the 2025 edition's misinformation category reflects the operational reality that this confidently-wrong output is being acted on in production systems with real consequences. The category covers both unintentional misinformation (the model "hallucinates" content the user treats as authoritative) and intentional misinformation (an attacker manipulates the model into producing content designed to deceive). The defenses overlap with LLM05 (improper output handling) and LLM02 (sensitive information disclosure) but center on the integrity of model output rather than its sanitization or its information content.

The defenses are grounding, verification, and user-side communication of confidence. Grounding means the model output is required to be supported by retrievable, citeable source material — the model should answer "based on the company policy document section 3" rather than from memory alone, and the citation should be checkable. Verification means high-stakes model output is independently verified before being acted on — a model that generates SQL is checked by a SQL parser; a model that generates legal analysis is reviewed by a human lawyer. Confidence communication means the user-facing presentation reflects appropriate uncertainty — model output should not be presented in the same authoritative voice as deterministic system output.

LLM10 — Unbounded Consumption

Unbounded consumption is the LLM-specific generalization of denial-of-service risk, with the 2025 edition's framing explicitly including cost denial-of-service. An attacker who can cause the application to generate large quantities of LLM output incurs both compute resources and direct cost on the application owner — and LLM APIs are priced on per-token usage in ways that allow this to be operationally meaningful. The traditional DoS model (the attacker exhausts compute capacity) is augmented in LLM applications by a cost DoS model (the attacker drives up the application's per-token costs to the point of financial damage even if compute is elastic).

The defenses are rate limiting, output length bounding, cost monitoring, and per-user budgeting. Rate limiting at the API gateway, scoped per user and per IP, prevents bulk exploitation. Output length bounding caps the number of tokens any single request can produce, even if the user's input would naturally elicit a longer response. Cost monitoring with per-user budget caps allows the application to refuse further requests from a user who has consumed their allocation. Per-user budgeting closes the loop — the cost of LLM usage is allocated against an explicit limit per user, beyond which the application stops issuing further model calls.

How the LLM Top 10 Maps to Existing Security Standards

The LLM Top 10 sits inside a larger application security ecosystem. The risks do not exist in isolation from the web application Top 10 categories the same applications also need to defend against, and they intersect with the verification standards an application's broader security program is anchored to. The pragmatic mappings are these.

To the OWASP Top 10 (web). LLM05 Improper Output Handling maps onto A03 Injection — both categories address the consequences of treating untrusted output as trusted input. LLM02 Sensitive Information Disclosure maps onto A02 Cryptographic Failures and A04 Insecure Design, depending on the specific failure mode. LLM06 Excessive Agency maps onto A01 Broken Access Control — both categories address the consequences of granting more capability than necessary. LLM03 Supply Chain maps onto A06 Vulnerable and Outdated Components. The overlap is substantial but not complete; LLM01 Prompt Injection and LLM07 System Prompt Leakage have no direct web-Top-10 analog.

To OWASP ASVS 5.0. The ASVS chapter mappings are not yet formalized as of mid-2026, but the natural fits are LLM01 Prompt Injection ↔ V1 Encoding and Sanitization; LLM02 Sensitive Information Disclosure ↔ V14 Data Protection; LLM05 Improper Output Handling ↔ V1 Encoding and Sanitization; LLM06 Excessive Agency ↔ V8 Authorization. The ASVS 5.0 developer guide covers the chapter structure that these mappings join into.

To MITRE ATLAS. The MITRE ATLAS framework — the ML-specific analog of the ATT&CK framework — has tactic and technique mappings that align with most LLM Top 10 categories. Teams running threat-modeling against an ATLAS-based threat library will find the LLM Top 10 categories correspond to ATLAS tactics with reasonable directness. Both frameworks are useful; ATLAS is more operationally oriented toward adversarial ML, the LLM Top 10 is more operationally oriented toward applied LLM deployment.

To NIST AI RMF. The NIST AI Risk Management Framework's GOVERN, MAP, MEASURE, MANAGE functions overlay onto the LLM Top 10 risks at the program level rather than the technical level. The LLM Top 10 tells you what to defend against; the NIST framework tells you how to organize the program that does the defending. Both are referenced in most enterprise LLM application security programs in 2026.

From Risk List to Implementation

The LLM Top 10, like the web Top 10, is a risk awareness list. Translating it into actual defensive engineering requires choosing where each risk's defenses live — at the model layer, the prompt layer, the input/output mediation layer, the application logic layer, or the infrastructure layer. The pattern that works in practice is to defend in depth across multiple layers rather than relying on any single layer being sufficient, because the LLM Top 10 risks have a higher proportion of defenses that fail under sustained adversarial pressure than the corresponding web Top 10 defenses do.

The minimal viable defense layer for most production LLM applications is: input mediation (prompt-injection filtering, classifier-based detection of attempt patterns, content-policy enforcement at the input gate), prompt hardening (system prompts written defensively, with explicit instructions to refuse certain categories of request), output mediation (the same content-policy enforcement applied to output, plus content-type-specific sanitization for outputs that flow into other systems), and operational monitoring (logging of inputs, outputs, and model behavior for anomaly detection and forensic analysis after incidents). This minimal layer is far from comprehensive, but it raises the bar against the easy attacks substantially and gives the team a foundation to build on as adversarial patterns evolve.

The more mature pattern adds runtime guardrails (the model's behavior is monitored against expected behavior in real time, with anomalies triggering escalation), red-teaming as a continuous activity (the application is exercised with adversarial inputs on a defined cadence, with findings driving defensive improvements), and an incident response capability specifically scoped to LLM-related incidents (the response pattern for a prompt injection that exfiltrated data is operationally different from the response pattern for a SQL injection that exfiltrated data, and the team needs to be drilled on the LLM-specific runbook).

The integration into the broader secure SDLC — covered in the secure SDLC pillar — looks similar to the integration of any other risk category. Threat modeling that explicitly covers LLM Top 10 risks during design. Security requirements derived from the LLM Top 10 during requirements gathering. Verification activities that exercise each LLM Top 10 category during the testing phase. Production monitoring that includes LLM-specific anomaly detection during the operations phase. The discipline is no different; the specific risks being addressed are.

Where to Go Deeper

Three threads from this overview merit their own dedicated treatments. The prompt injection deep dive is the prompt injection developer guide, which covers the 10 attack categories, the 12 static defenses, and the red-team methodology at the depth a developer building defenses against this class needs — far more than the LLM01 section above can. The agentic AI extension — the LLM Top 10 categories as they apply to autonomous agentic systems plus the OWASP Agentic AI Top 10 risks — is covered in the agentic AI security guide. The broader application security verification framing — how LLM Top 10 risks land inside an ASVS-anchored verification program — sits inside the ASVS 5.0 developer guide.