Securing LLM applications
The OWASP Top 10 is the checklist every team building on LLMs should know. This module walks through it with practical controls.
Learning objectives
- Name the ten OWASP LLM risks
- Prevent sensitive information disclosure
- Handle model output safely
- Protect against system prompt leakage and RAG weaknesses
- Control misinformation and unbounded consumption
4.1 The OWASP Top 10 for LLM Applications (2025)
| ID | Risk | In one line |
|---|---|---|
| LLM01 | Prompt Injection | Inputs manipulate the model's behaviour (Module 2) |
| LLM02 | Sensitive Information Disclosure | The app leaks personal data, secrets or confidential information |
| LLM03 | Supply Chain | Compromised models, data, libraries or plugins (Module 3) |
| LLM04 | Data and Model Poisoning | Manipulated training, fine-tuning or retrieval data (Module 3) |
| LLM05 | Improper Output Handling | LLM output passed unchecked into other systems |
| LLM06 | Excessive Agency | Too much functionality, permission or autonomy (Module 5) |
| LLM07 | System Prompt Leakage | Secrets or security logic exposed via the system prompt |
| LLM08 | Vector and Embedding Weaknesses | Weaknesses in RAG pipelines and vector databases |
| LLM09 | Misinformation | False or misleading outputs that people rely on |
| LLM10 | Unbounded Consumption | Uncontrolled resource use: cost blow-ups, denial of service, model extraction |
4.2 Sensitive information disclosure (LLM02)
- Don't give the model access to data the user isn't allowed to see — enforce permissions outside the model
- Minimise sensitive data in prompts, fine-tuning and logs
- Filter outputs for personal data and secrets where appropriate
- Check provider terms for data retention and training use
4.3 Improper output handling (LLM05)
Treat LLM output like untrusted user input. If output flows into a web page, database query, shell command or another system without validation, an attacker who can influence the model (e.g. through prompt injection) can trigger classic attacks such as cross-site scripting or SQL injection.
Python: never trust model outputimport html
reply = call_llm(user_question) # untrusted!
# BAD: inserting raw output into a web page enables XSS
# page = f"<div>{reply}</div>"
# BETTER: escape before rendering as HTML
page = f"<div>{html.escape(reply)}</div>"
# For SQL, use parameterised queries — never build SQL from model output
cursor.execute("SELECT * FROM orders WHERE id = ?", (order_id,))4.4 System prompt leakage (LLM07)
Assume your system prompt will be extracted. Never put credentials, API keys, internal URLs or security rules that must be enforced into it. Enforce access control and business rules in code, outside the model.
4.5 Vector and embedding weaknesses (LLM08)
Retrieval-augmented generation adds a knowledge base — and new risks:
- Access control: a single vector store shared across users or tenants can leak documents to people who shouldn't see them. Filter retrieval by the user's permissions.
- Poisoned documents: anyone who can add content to the knowledge base can plant instructions (indirect injection) or misinformation.
- Embedding inversion: embeddings can sometimes be reversed to reveal source text, so protect them as sensitive data.
4.6 Misinformation (LLM09)
Hallucinated outputs become a security and liability issue when people or systems act on them — for example, a chatbot inventing a refund policy, or a coding assistant recommending a non-existent package. Ground answers in authoritative sources, show citations, communicate limitations and keep humans in the loop for consequential outputs.
4.7 Unbounded consumption (LLM10)
LLM calls cost money and compute. Without limits, attackers (or bugs) can run up huge bills ("denial of wallet"), degrade service or extract a model through mass querying. Controls: authentication, per-user rate limits and quotas, maximum input and output lengths, timeouts, budget alerts and monitoring.
Key takeaways
- Know all ten OWASP LLM risks.
- Enforce permissions outside the model.
- Treat model output as untrusted input — escape and parameterise.
- Assume system prompts leak.
- Filter retrieval by user permissions and protect knowledge bases.
- Rate-limit, cap and budget LLM usage.