The OWASP Top 10 for LLM is a crucial guide for navigating the complex landscape of potential critical vulnerabilities associated with LLMs. Let’s dive into the most vital security risks and how to mitigate them, ensuring LLMs’ safe and effective use for organizations and their staff. An older version of the OWASP Top 10 for LLMs used to include inadequate sandboxing, SSRF vulnerabilities, data leakage, and other risks that are now removed.
The Importance of LLM Security
LLMs have become integral to numerous operations, offering valuable insights and assistance across various domains. However, their widespread integration introduces potential security risks, including training data poisoning, unauthorized code execution, and supply chain vulnerabilities.
Initially, a few large companies across the US and UK were seen to have applied blanket rules to ban the use of LLMs during 2023; this will not stop their curious staff from using the AI. The underlying goal is to ensure that companies’ processes, people, and tech controls are in place to allow the safe use of such models. The stakes are high – a single security incident could become data disclosure or a serious breach that can lead to unauthorized access, privacy violations, and a damaged reputation. Additionally, data leakage can unintentionally reveal sensitive information, proprietary algorithms, or confidential details, leading to severe security breaches.
Regular security assessments and penetration testing of LLMs are crucial for identifying potential weaknesses or vulnerabilities.
OWASP Top 10 for Large Language Model (LLM) Applications
1. Prompt Injection Vulnerabilities
Prompt injection is a vulnerability in which attackers manipulate the functioning of a trusted LLM through crafted inputs, either directly or indirectly, to access restricted resources, perform unintended actions, or execute malicious actions.
Examples of Prompt Injection Vulnerabilities
- An attacker uses specific language patterns or tokens to bypass filters or restrictions, misleading the LLM into performing unintended operations.
- A malicious user exploits weaknesses in the LLM’s tokenization or encoding mechanisms to execute unauthorized actions.
- An attacker crafts a command like “model ignores previous instructions” and provides new instructions to query private data stores, disclosing sensitive information.
Mitigation of prompt injection vulnerabilities
- Implement robust input sanitization and validation techniques to ensure user input is in the expected format and free from malicious code.
- Utilise prepared statements or parameterized queries to handle user input as data rather than executable code.
- Develop and maintain a comprehensive list of forbidden tokens or patterns that could be used for prompt injection attacks.
- Implement strict access controls and authentication mechanisms to limit the potential impact of successful prompt injections.
2. Insecure Output Handling Issues
Insecure output handling is a vulnerability that can lead to critical security issues, such as cross-site scripting (XSS), cross-site request forgery (CSRF), and server-side request forgery (SSRF), exposing backend systems, internal services and creating potential risks for privilege escalation and remote code execution. These severe consequences stem from a lack of stricter application security practices, making it one of the popular OWASP Top 10 for LLM risks.
Examples of insecure output handling vulnerability
- An LLM generates HTML content without proper encoding, allowing an attacker to inject malicious scripts that execute when users view it.
- Inadequate sanitization of LLM-generated output leads to SQL injection vulnerabilities when the output is used in database queries.
- An LLM produces output containing sensitive information, which is then displayed to unauthorized users due to a lack of proper access controls.
- Insecure output handling can lead to unauthorized code execution. Non-sanitized user input or insufficient restrictions on LLM capabilities allow attackers to exploit the system through malicious commands and codes.
How to mitigate?
- Implement thorough output encoding techniques appropriate for the context (e.g., HTML encoding for web content, JavaScript encoding for script content).
- Utilise content security policies (CSP) to restrict the types of content that can be loaded and executed on web pages.
- Implement strict input validation and sanitization for any data generated by LLM outputs.
- Employ stricter application security access controls and authentication mechanisms to ensure that sensitive information is only displayed to authorized users.
- Regularly audit and test LLM-generated outputs for potential security vulnerabilities.
3. Training Data Poisoning
Training data poisoning in LLMs involves introducing false or malicious information into the training data, which can lead to biased models, potentially introducing vulnerabilities, backdoors, unintended biases or ethical behaviour. Some commonly used training data sources include:
- Common Crawl
- WebText
- OpenWebText
- Books
Common Examples of Vulnerability
- An attacker injects biased or false information into publicly available datasets used for training LLMs, resulting in the model introducing vulnerabilities and producing biased or inaccurate responses.
- Malicious actors manipulate training data to introduce subtle backdoors that can be exploited later to bypass security measures or extract sensitive information.
- Adversaries poison fine-tuning datasets to make the model more susceptible to specific attacks or to produce desired outputs in certain scenarios.
How to prevent data poisoning attacks?
- Implement rigorous data validation and cleaning processes for all training datasets, including those from public sources.
- Utilise diverse and well-curated datasets from reputable sources to minimize the risk of poisoned data.
- Employ anomaly detection techniques to identify and remove potentially poisoned data points from training sets.
- Regularly evaluate model outputs for unexpected biases or behaviours indicating successful poisoning attempts.
- Implement secure supply chain practices for acquiring and managing training data, including properly vetting data providers and sources.
4. Model Denial of Service
Model Denial of Service (MDoS) is an AI security vulnerability where an attacker engages with an LLM in a resource-heavy operations manner, resulting in service degradation for other users or increased resource costs for the organization.
Common Examples of Vulnerability
- An attacker floods an LLM-based chatbot with complex queries, consuming excessive computational resources and slowing down responses for legitimate users.
- A malicious actor exploits the LLM’s tendency to generate lengthy responses by crafting prompts that result in highly long outputs, depleting system resources.
- Coordinated attacks from multiple sources overwhelm the LLM’s infrastructure, causing service outages or significantly increased operational costs.
How to prevent it?
- Implement rate limiting and request throttling to prevent individual users or IP addresses from overwhelming the system.
- Set up resource allocation strategies to ensure fair distribution of computational power among users.
- Employ input validation techniques to identify and block potentially resource-intensive queries before they reach the LLM.
- Implement monitoring systems to detect unusual resource consumption patterns and trigger automated responses or alerts.
- Utilise load balancing and auto-scaling solutions to distribute traffic and maintain service availability during high-demand periods.
Cyber attacks are not a matter of if, but when. Be prepared.
Box-ticking approach to penetration tests is long gone. We help you identify, analyse and remediate vulnerabilities so you don’t see the same pentest report next time.
5. Supply Chain Vulnerabilities
Supply chain vulnerabilities in LLMs refer to security risks introduced through the various components and processes involved in developing, training, and deploying language models, including pre-trained models, external training data, and third-party plugins.
Common Examples of Vulnerability
- An attacker exploits vulnerabilities in a popular open-source library in LLM development, potentially compromising numerous downstream applications.
- Malicious actors manipulate third-party datasets for fine-tuning, introducing biases or backdoors into the model.
- Insecure plugins or extensions integrated into an LLM system allow attackers to gain unauthorized access to sensitive information or system resources.
How do we mitigate against supply chain attacks?
- Implement a robust vendor risk management programme to assess and monitor the security practices of third-party suppliers and partners.
- Regularly audit and update all components of the LLM pipeline, including libraries, frameworks, and plugins.
- Establish a secure software development lifecycle (SDLC), including thorough security testing and code review processes.
- Implement strong access controls and authentication mechanisms for all components of the LLM system.
- Maintain an up-to-date inventory of all third-party components and dependencies in the LLM pipeline.
6. Sensitive Information Disclosure
Sensitive information disclosure occurs when an LLM inadvertently reveals confidential or private information through its responses or by exposing internal system details.
Common Examples of Vulnerability
- An LLM trained on a dataset containing personal information accidentally reveals user data in its responses.
- A poorly configured LLM exposes details about its internal architecture or training process, potentially aiding attackers in exploiting vulnerabilities.
- An LLM with access to internal databases unintentionally discloses proprietary business information when responding to user queries.
How to prevent this vulnerability?
- Implement robust data sanitization processes to remove sensitive information from training datasets.
- Utilise differential privacy techniques to protect individual privacy while maintaining the utility of the training data.
- Employ strict access controls and authentication mechanisms to limit the LLM’s access to sensitive information.
- Regularly audit and test the LLM’s responses for potential information leakage.
- Implement content filtering and output sanitization to prevent the disclosure of sensitive information in responses.
7. Insecure Plugin Design
Insecure plugin design refers to vulnerabilities introduced through poorly implemented or inadequately secured plugins or extensions that expand an LLM’s functionality.
Common Examples of Vulnerability
- A plugin with insufficient input validation allows attackers to inject malicious code, leading to remote code execution.
- An improperly secured plugin grants excessive permissions, enabling unauthorized access to sensitive system resources.
- A plugin with weak authentication mechanisms allows attackers to bypass security controls and manipulate the LLM’s behaviour.
Secure code is an essential element for business growth
Show your customers and supply chain you can manage application risks with secure coding practices.
How do we prevent insecure plugin design flaws?
- Implement a rigorous security review process for all plugins before integration into the LLM system.
- Enforce strict input validation and sanitization for all data processed by plugins.
- Apply the principle of least privilege, granting plugins only the minimum necessary permissions to function.
- Regularly audit and update plugins to address newly discovered vulnerabilities.
- Implement strong authentication and access control mechanisms for all plugin interactions.
8. Excessive Agency
Excessive agency occurs when an LLM is granted excessive functionality or decision-making power, potentially leading to unintended consequences or security risks.
Common Examples of Vulnerability
- An LLM with unrestricted access to system resources inadvertently consumes excessive computational power, causing service disruptions.
- An autonomous LLM-powered chatbot makes inappropriate or harmful decisions without human oversight.
- An LLM with excessive permissions modifies critical system configurations, potentially compromising security or stability.
How do we prevent excessive agency vulnerabilities?
- Clearly define and enforce boundaries for the LLM’s decision-making capabilities and autonomy.
- Implement robust monitoring and logging systems to track the LLM’s actions and decisions.
- Establish human-in-the-loop processes for critical decisions or actions taken by the LLM.
- Review and adjust the LLM’s permissions and access levels regularly to ensure they align with business requirements and security policies.
- Conduct thorough testing and simulation of the LLM’s behaviour in various scenarios to identify potential risks associated with excessive agency.
9. Overreliance on LLMs
Overreliance on LLMs occurs when organizations or individuals place excessive trust in the outputs or capabilities of language models without adequate verification or human oversight.
Common Examples of Vulnerability
- A company relies solely on LLM-generated content for critical business reports, potentially propagating errors or biases.
- Security teams over-trust LLM-generated threat intelligence without proper verification, leading to misallocating resources or missed threats.
- Customer support systems automatically implement LLM-suggested solutions without human review, potentially causing further user issues.
How to prevent it?
Preventing overreliance on LLMs requires the following mitigation measures:
- Establish clear guidelines and processes for using LLM-generated content, including mandatory human review for critical applications.
- Implement a system of checks and balances, combining LLM outputs with human expertise and other information sources.
- Regularly evaluate the accuracy and reliability of LLM outputs through audits and comparison with ground truth data.
- Provide comprehensive training to staff on the capabilities and limitations of LLMs to promote responsible use.
- Implement feedback loops to improve the LLM’s performance and address continuously identified shortcomings.

10. Model Theft
Model theft refers to the unauthorized acquisition or replication of proprietary LLM models, which can potentially lead to intellectual property loss, competitive disadvantage, or security compromises.
Common Examples of Vulnerability
- A malicious insider exfiltrates the weights and architecture of a proprietary LLM, allowing competitors to replicate the model.
- Attackers use model inversion techniques to reconstruct training data from a publicly accessible LLM API, inadvertently revealing confidential data.
- Competitors use repeated queries to a public LLM service to approximate its functionality, creating a similar model without incurring training costs.
How to prevent it?
- Implement strong access controls and authentication mechanisms to protect model files and training infrastructure.
- Use encryption and secure key management practices to protect model weights and architecture details.
- Employ watermarking or fingerprinting techniques to identify and trace stolen or replicated models.
- Implement rate limiting and monitoring on public LLM APIs to detect and prevent potential model extraction attempts.
- Consider using techniques like differential privacy or federated learning to protect the privacy of training data and make model theft more challenging.
Summary
The OWASP Top 10 for Large Language Models (LLMs) is a valuable resource for data scientists, security experts and developers to identify and mitigate potential vulnerabilities in their LLM applications. As LLM technology leveraging machine learning continues to evolve, organizations must stay vigilant and proactive in addressing flaws, ensuring a safe and reliable environment for LLM applications through a well-defined application security strategy.
Frequently Asked Questions on OWASP AI Security
What is the purpose of the OWASP Top 10 for Large Language Models (LLMs)?
The OWASP Top 10 for LLM provides a guide to identify and address AI security vulnerabilities, ensuring their artificial intelligence models’ security, integrity, and effectiveness.
What is a prompt injection vulnerability?
A prompt injection vulnerability is a security risk in which an attacker manipulates inputs to access restricted resources or execute malicious actions.
What are the potential consequences of model theft?
Model theft can lead to economic detriment, loss of competitive advantage, and unauthorized access to confidential information, all of which have serious repercussions.
How can organizations reduce the risks associated with overreliance on LLMs?
Organizations can reduce the risks associated with LLMs by implementing secure development practices, adhering to coding standards, conducting security audits, and reviewing their usage.
Why is LLM security important?
LLM safety is crucial because these models often handle sensitive information and can significantly impact decision-making processes. Ensuring their security helps prevent data breaches, maintain user trust, and protect against potential misuse or manipulation of AI systems.
How often should organizations assess their machine learning security?
Organizations should conduct regular security assessments of their LLM systems, ideally on a quarterly basis or whenever significant changes are made to the model or its infrastructure. Additionally, continuous monitoring should be implemented to detect potential security issues in real time.
What are the most critical security risks for LLMs?
While all the risks in the OWASP Top 10 for LLMs are significant, prompt injection, insecure LLM output handling, and training data poisoning are often considered among the most critical due to their potential for widespread impact and the challenges in detecting and mitigating them.
What role do human oversight and ethics play in AI security?
Human oversight and ethical considerations are crucial in LLM security. They help ensure that AI (machine learning) systems are used responsibly, prevent unintended consequences of excessive agency, and provide necessary checks and balances against overreliance on automated systems.





