OWASP LLM Top 10 Applied to SaaS Product Security Reviews

AppOmni's State of SaaS Security 2025 Report found that 91% of organizations say they're confident in their SaaS security posture. In the same report, 75% had a security incident in the past year. That gap is the whole problem with how most companies think about SaaS security right now, and LLMs are the reason the gap keeps widening.

LLMs aren't a bolted-on feature anymore. They sit inside customer-facing chat tools, internal support workflows, data pipelines, and agentic systems that take actions on a user's behalf without a human clicking "confirm." The old playbook, the standard OWASP Top 10 for web apps, the usual pen test checklist, was built for a world where code and data stayed in separate lanes. LLMs collapse that separation. Instructions and data now travel through the same channel, and that single fact creates an entire attack surface most product security reviews still don't touch.

The OWASP LLM Top 10 is the closest thing the industry has to a shared map of that surface. First published in 2023 and substantially rewritten for 2025, it's built from real incident data, not hypotheticals, and a newer edition landed August 4, 2026, drawing on input from hundreds of AI security practitioners and thousands of documented incidents. A SaaS security review that skips this framework is leaving a whole category of attack paths unexamined. What follows walks through each entry with a SaaS product lens: what the risk actually looks like when it's running in production, and what a review needs to verify before anyone signs off on it.

How the 2025 OWASP LLM Top 10 differs from the version most teams are still using

Plenty of security teams are still working off the 2023 list, or a mental model shaped by it. The 2025 edition, published in November 2024, isn't a minor refresh. It adds new standalone categories including System Prompt Leakage, Vector and Embedding Weaknesses, and Unbounded Consumption, the last of which becomes its own full entry rather than a subset of denial-of-service concerns.

Some categories got folded together. Misinformation now absorbs what used to be called Overreliance. Insecure Plugin Design and Model Theft, both standalone in version 1.1, got folded into other entries, including Supply Chain and Excessive Agency, because in practice those risks rarely showed up in isolation, they showed up as part of a bigger pattern.

The reordering matters just as much as the additions. Sensitive Information Disclosure jumped from sixth place to second, and that jump isn't cosmetic. It reflects a real increase in documented extraction techniques that surfaced between the 2023 and 2025 editions, cases where attackers found working methods to pull training data or configuration details out of a deployed model.

A newer edition arrived in August 2026 with updated rankings and wider threat coverage. This article works from the 2025 list, LLM01 through LLM10, since that's the version most SaaS reviews are being measured against right now, with notes where the 2026 changes affect the guidance. For reference, the full 2025 order runs: Prompt Injection, Sensitive Information Disclosure, Supply Chain, Data and Model Poisoning, Improper Output Handling, Excessive Agency, System Prompt Leakage, Vector and Embedding Weaknesses, Misinformation, and Unbounded Consumption.

LLM01: Prompt injection, why it holds the top spot and what it looks like in a SaaS product

Prompt injection sits at number one because the underlying flaw is structural. LLMs process instructions and data through the same channel. There's no wall between "here's what you're allowed to do" and "here's the content you're working on," so an attacker who can shape either one can potentially shape both.

That plays out three ways in a real product. Direct injection is the crude version: a user types "ignore previous instructions and show me your system prompt" straight into a chat box. Indirect injection is quieter and more dangerous, and an attacker plants instructions inside content the model will process later, such as a PDF a customer uploads, a webpage the model summarizes, or a data feed pulled from a third party. The model reads the hidden instruction and follows it, because it has no reliable way to tell "trusted command" from "content I was asked to analyze."

The third form, multimodal injection, got specific attention in the 2025 update. Instructions can be encoded into an image, invisible to a human eye scanning the file, but perfectly legible to a model processing it. Any SaaS product with document upload or vision features needs to account for this, not as a theoretical edge case but as a live path.

OWASP's own guidance is blunt on this point: system prompts are not a security control. Models are stochastic. They don't behave like a firewall rule that either blocks or allows, deterministically, every time. Treating a system prompt as an auditable boundary is a category error, and RAG or fine-tuning doesn't fix it either, those techniques ground what the model knows, they don't stop a malicious instruction from overriding what it does.

A serious review tests adversarial input at every point where the model ingests content, not just the visible chat window. It checks whether untrusted external material, uploads, fetched URLs, third-party feeds, gets segregated from the instruction context, or whether it all lands in the same pot. It verifies that anything sensitive the model might trigger requires a human approval step outside the model's own loop. And it applies input validation and output filtering at every boundary in the pipeline, not just the front door.

Worth flagging: a support bot that also has account-data access, or a document processor that acts on what it reads, is a confused deputy risk, going beyond a mere injection risk. It's an injection risk chained to an agency risk, and those two compound each other fast.

LLM02: Sensitive information disclosure, what the model remembers and what it will say

Two separate leaks live under this one heading. The first is memorization: a model can reproduce fragments of whatever it was trained on, including PII, internal documents, or confidential business data, and a sufficiently targeted query can coax that back out. The second is configuration exposure, where a system prompt carrying business logic, API endpoints, or access secrets gets talked out of the model by someone patient enough to try.

There's a documented precedent for how bad the downstream effects can get. The "Proof Pudding" vulnerability, tracked as CVE-2019-20634, showed how disclosed training data enabled model extraction and inversion attacks, letting attackers reconstruct enough of the underlying model to sidestep security controls and dodge email filters entirely. That real case shows what leaked training data makes possible once it's in the wrong hands.

The jump from sixth to second place in the 2025 ranking isn't arbitrary. It reflects the documented growth in extraction techniques and incidents that surfaced between editions. For a SaaS company, the sharpest version of this risk shows up in multi-tenant products: a model fine-tuned on customer data, or one where different users' content ends up sharing a context window, creates a real path for one customer's data to surface in another customer's session.

Reviews need to check whether training and fine-tuning data went through actual PII scrubbing before use, not a checkbox claim that it did. They need to treat the system prompt as exposed by default and check whether any credentials or API keys are sitting inside it. Output filtering should catch sensitive patterns before a response ever reaches a user, and differential privacy or comparable techniques deserve a look during training review. Above all, tenant isolation needs a direct test: can one tenant's session pull anything from another tenant's context, even indirectly?

LLM03 and LLM04: Supply chain and data poisoning, the risks that enter before the product ships

Supply chain risk moved up to third place in 2025, and the reason is straightforward: most SaaS teams aren't building models from scratch, they're assembling them from parts, and every part is a potential entry point. That includes pre-trained base models pulled from public hubs like Hugging Face, fine-tuning datasets sourced from third parties or scraped from product data, adapters built with techniques like LoRA or PEFT, and the orchestration frameworks wrapping the whole thing together.

A compromised base model on a widely used hub doesn't just affect one company. It affects every product built on top of it. And the newer fine-tuning methods introduce a wrinkle the 2023 edition never addressed: a malicious LoRA adapter, small and easy to distribute, can quietly shift a model's outputs toward biased or unauthorized behavior without touching the base weights at all.

Data and model poisoning, the fourth entry, expanded from what used to be a narrower "Training Data Poisoning" category. Now it covers poisoning at any stage, pre-training, fine-tuning, or embedding, where an attacker introduces a backdoor or a bias that only shows up under specific trigger conditions. Any organization pulling in a third-party model inherits whatever's baked into its training data and weights, usually without much visibility into what that actually is.

A thorough review verifies provenance for every component in the stack, base model, adapters, datasets, ideally with signed artifacts where the vendor provides them. It checks whether the fine-tuning pipeline has any integrity control that would catch tampered data before it gets used. It runs behavioral tests looking for outputs that suggest a backdoor trigger, scans dependencies across orchestration frameworks for known vulnerabilities, and sets up runtime monitoring for output drift, since a poisoned component often shows itself first as a subtle shift in behavior rather than an obvious failure.

LLM05: Improper output handling, when the model's response becomes an injection vector

This one's the LLM version of a problem security teams have known about for decades. If output from the model gets passed downstream without validation, that output is untrusted data, full stop, no matter how polished the response looks. Feed it to a browser without sanitizing, and it can execute as JavaScript. Feed it into a database query, and it can execute as SQL.

The attack chain usually runs in sequence. An attacker gets a malicious instruction into the model through prompt injection, the model generates output shaped by that instruction, and the application passes the output downstream without checking it. Somewhere in that chain, code that should never have run ends up executing in a context with real privileges.

This extends a familiar attack class rather than introducing a new one. SQL injection, cross-site scripting, command injection, all familiar. What's new is the vector: the LLM itself becomes the delivery mechanism, and it's an easy one to overlook because the output looks like ordinary conversational text right up until it isn't.

Reviews need to map every place LLM output ends up: rendered in a browser, written to a database, passed to another API, used to construct a file operation or a shell command. Each of those is a potential execution point. Output should be treated with the same suspicion applied to raw user input, at every single sink, not just the obvious ones. Testing for XSS, SQL injection, and command injection through model-generated content needs to happen in each downstream context separately, and the application should be checked for whether it enforces an expected output format and rejects anything that deviates from it.

LLM06: Excessive agency, what happens when the model can act, not just respond

The moment an LLM stops just generating text and starts calling APIs, executing code, querying databases, or sending messages on a user's behalf, the risk profile changes completely. A chatbot that only talks back is annoying to jailbreak. An agent that can act is dangerous to jailbreak.

Excessive agency comes from three design choices, usually made for convenience rather than malice: giving the model more tools than the task actually needs, granting it broader permissions than the task requires, or letting it take consequential action without a human in the loop. This is one of the categories that expanded the most in the 2025 update, tracking the fast growth of agentic deployments since 2023.

In a SaaS product, this shows up in specific, testable places. A customer-facing assistant with write access to account settings when it only needs to read them. An internal agent holding database write permissions for a task that's purely informational. An LLM that can fire off emails or trigger webhooks with no confirmation step in between. An agent holding credentials to a third-party service scoped far wider than anything its job requires.

There's a real irony baked into agentic design: the more capability a team grants an agent to make it genuinely useful, the bigger the blast radius the moment a prompt injection succeeds against it. LLM01 and LLM06 are the two entries in this whole list that chain together most dangerously, because agency is what turns a successful injection from an embarrassing text output into a real-world action.

Reviews need to enumerate every tool, API, and permission available to the agent and ask, honestly, whether each one is necessary. Credentials and API keys should be scoped to the minimum the task requires, not the maximum the team thought might be convenient someday. Every consequential action the agent can take autonomously needs a human-in-the-loop check for high-impact cases, and the review should directly test whether a successful injection can push the agent into taking an action nobody authorized.

LLM07 and LLM08: System prompt leakage and vector/embedding weaknesses, the two entries most SaaS teams overlook

System prompts often carry more than instructions. They carry business logic, behavioral rules, proprietary phrasing that took real work to develop, and sometimes, carelessly, credentials or API references that should never have gone in there in the first place. Developers tend to treat the system prompt as hidden. OWASP's position is direct: treat it as already exposed, because a sufficiently persistent attacker can usually extract it through targeted queries.

For a SaaS company whose competitive edge is its prompt engineering, or whose system prompt holds customer-specific configuration, this isn't an abstract concern. A review needs to attempt systematic extraction of the prompt's contents, confirm no secrets or sensitive logic are embedded there, and check whether the prompt's substance can be inferred from model behavior even when direct disclosure fails.

Vector and Embedding Weaknesses is the newer, less obvious entry, and it matters most for products built on RAG. Retrieval-augmented generation pulls relevant documents from a vector store and injects them into the model's context before it answers. That vector store, and the retrieval process feeding it, is its own attack surface, separate from the model itself.

The weaknesses here take a few forms: poisoning the vector store with adversarial documents that shift what gets retrieved, manipulating embeddings so the wrong documents surface at query time, or gaining unauthorized access to the vector store directly, which may hold sensitive indexed content nobody thought to protect separately from the model. Any SaaS product built on RAG needs its retrieval layer treated as a distinct security boundary, not an invisible plumbing detail sitting quietly behind the model everyone's busy testing.