Die OWASP Top 10 für LLMs

Die OWASP Top 10 für Anwendungen mit großen Sprachmodellen ist eine von der Community erstellte Liste der kritischsten Sicherheitsrisiken für Systeme, die auf LLMs basieren. Sie orientiert sich an der bekannten OWASP Web Top 10, behandelt jedoch Bedrohungen, die klassische AppSec-Listen nicht abdecken.

Sie wurde erstellt, weil LLM-Anwendungen eine neue Angriffsfläche einführen: Kontrollfluss in natürlicher Sprache, nichtdeterministische Ausgaben, Modell-Lieferketten und autonome Agenten. Die Liste bietet Sicherheitsteams ein gemeinsames Vokabular und eine Checkliste für die Bedrohungsmodellierung.

Die folgenden Codes verwenden die Nummerierung LLM01–LLM10 aus der Ausgabe von 2025.

LLM01: Prompt-Injection ist durchgehend das Risiko Nummer eins. Vom Angreifer kontrollierter Text überschreibt die Anweisungen der Entwicklerin oder des Entwicklers, weil das Modell vertrauenswürdige Anweisungen nicht von nicht vertrauenswürdigen Daten unterscheiden kann.

• Direkt: Die Benutzerin oder der Benutzer gibt überschreibende Anweisungen ein.
• Indirekt: Anweisungen sind in abgerufenen Webseiten, Dateien oder Tool-Ausgaben verborgen.

Gegenmaßnahmen: Wenden Sie für Tools das Prinzip der geringsten Berechtigungen an, behandeln Sie alle abgerufenen Inhalte als Daten, fügen Sie für sensible Aktionen menschliche Kontrollpunkte hinzu und unterbrechen Sie den Pfad zur Datenexfiltration.

LLM02: Offenlegung sensibler Informationen umfasst Fälle, in denen das Modell Daten preisgibt, die es nicht preisgeben sollte: personenbezogene Daten (PII), Geheimnisse, proprietäre Trainingsdaten oder Informationen eines anderen Mandanten.

Zu Datenlecks kommt es durch auswendig gelernte Trainingsdaten, eine zu weit gefasste Kontextinjektion oder System-Prompts, die Zugangsdaten enthalten.

• Bereinigen und minimieren Sie die Daten, die Sie in den Kontext aufnehmen.
• Fügen Sie niemals aktive Geheimnisse in Prompts ein, sondern verwenden Sie außerhalb des Prompts übermittelte, auf den erforderlichen Umfang beschränkte und kurzlebige Tokens.
• Wenden Sie vor der Rückgabe von Antworten Ausgabefilter und Prüfungen zur Verhinderung von Datenverlusten an.

LLM03: Lieferkette betrifft Risiken durch Modelle, Datensätze, Plugins und Bibliotheken von Drittanbietern. Ein vergiftetes Basismodell, ein mit einer Hintertür versehenes Fine-Tuning aus einem Model Hub oder eine schädliche Python-Abhängigkeit kann die gesamte Anwendung kompromittieren.

• Überprüfen Sie die Herkunft und die Prüfsummen von Modellen.
• Fixieren Sie Versionen und prüfen Sie Lizenzen.
• Überprüfen Sie mit pickle serialisierte Modelldateien (pickle kann beim Laden Code ausführen) und bevorzugen Sie sichere Formate wie safetensors.

LLM04: Vergiftung von Daten und Modellen zielt auf die Trainings- oder Fine-Tuning-Pipeline. Ein Angreifer, der Trainingsdaten beeinflussen kann, kann Hintertüren (verborgene Auslöser) einschleusen, Ausgaben verzerren oder die Qualität verschlechtern.

RAG-Pipelines, die von Benutzern eingereichte Dokumente aufnehmen, bleiben auch nach der Bereitstellung eine aktive Angriffsfläche für Vergiftung.

• Prüfen und signieren Sie Quellen von Trainingsdaten.
• Verwenden Sie Anomalieerkennung für Datensätze.
• Isolieren und prüfen Sie von Benutzern beigesteuerte Inhalte, bevor Sie sie indizieren.

LLM05: Unsachgemäße Verarbeitung von Ausgaben tritt auf, wenn nachgelagerte Komponenten Modelausgaben ohne Validierung vertrauen. Da Ausgaben durch Injektionen von Angreifern beeinflusst werden können, führt ihre ungeprüfte Übergabe an eine Shell, eine SQL-Abfrage, einen Browser oder eval direkt zu XSS, SSRF oder RCE.

Regel: Behandeln Sie LLM-Ausgaben genau wie nicht vertrauenswürdige Benutzereingaben. Kodieren, validieren und sand-boxen Sie sie, bevor sie einen Interpreter erreichen.

LLM06: Übermäßige Handlungsautonomie bezeichnet Schäden, die dadurch entstehen, dass dem Modell zu viele Funktionen, zu viele Berechtigungen oder zu viel Autonomie gegeben werden. Wenn das Modell Tools aufrufen kann, wird eine Injektion zu einer Aktion und bleibt nicht nur Text.

• Übermäßige Funktionalität: Tools, die die Anwendung tatsächlich nicht benötigt.
• Übermäßige Berechtigungen: Ein Tool mit Schreib- und Löschrechten, obwohl Lesen ausreicht.
• Übermäßige Autonomie: Aktionen mit großer Wirkung ohne menschliche Genehmigung.

Wenden Sie für jedes Tool das Prinzip der geringsten Berechtigungen an und verlangen Sie für nicht umkehrbare Vorgänge eine Bestätigung.

LLM07: Offenlegung des System-Prompts macht deutlich, dass System-Prompts kein sicherer Ort für Geheimnisse sind. Angreifer können sie oft extrahieren, und sie enthalten manchmal Zugangsdaten, verborgene Geschäftslogik oder Filterregeln, die weitere Angriffe erleichtern.

• Gehen Sie davon aus, dass der System-Prompt rekonstruiert werden kann; betten Sie niemals Geheimnisse oder Schlüssel darin ein.
• Setzen Sie die Autorisierung im Backend durch, anstatt darauf zu hoffen, dass eine Prompt-Regel eingehalten wird.
• Betrachten Sie jede Sicherheitsmaßnahme als unwirksam, wenn sie ausschließlich im Prompt-Text verankert ist.

Die verbleibenden Einträge:

• LLM08 Schwachstellen bei Vektoren und Embeddings: Risiken in RAG-Embeddings, etwa mandantenübergreifende Datenlecks, Embedding-Invertierung und die Indizierung vergifteter Dokumente. Setzen Sie die Zugriffskontrolle zum Zeitpunkt des Abrufs durch.
• LLM09 Fehlinformationen: selbstsichere Halluzinationen und übermäßiges Vertrauen. Fügen Sie für Ausgaben mit hohem Risiko eine Verankerung in Quellen, Zitate und menschliche Prüfung hinzu.
• LLM10 Unbegrenzter Verbrauch: Denial-of-Wallet und DoS durch teure oder ausufernde Abfragen. Wenden Sie Ratenbegrenzungen, Token-Budgets, Timeouts und Kostenwarnungen an.

Die Top 10 ist als strukturierte Checkliste während einer Designprüfung am nützlichsten:

• Ordnen Sie jede Komponente (Eingabe, Abruf, Tools, Ausgabe) den relevanten LLM-Risiken zu.
• Bestimmen Sie für jedes Risiko eine konkrete Maßnahme und eine verantwortliche Person.
• Formulieren Sie Missbrauchsszenarien und machen Sie daraus automatisierte Tests.

Kombinieren Sie sie mit bestehenden Frameworks wie der standardmäßigen OWASP Top 10, MITRE ATLAS für ML-spezifische Taktiken und dem NIST AI Risk Management Framework für Governance.

Keine einzelne Maßnahme deckt diese Risiken ab. Schichten Sie mehrere Maßnahmen:

• Eingabeschicht: Validierung, Klassifizierung, Ratenbegrenzungen.
• Modellebene: Tools mit den geringsten Berechtigungen, begrenzter Kontext, Guard-Modelle.
• Ausgabeschicht: Validierung, Kodierung, DLP, menschliche Genehmigung.
• Plattformebene: Protokollierung, Überwachung, Überprüfung der Lieferkette, Kostenkontrollen.

Gehen Sie davon aus, dass jede einzelne Schicht ausfallen kann, und entwerfen Sie das System so, dass ein einzelner Ausfall nicht zu einem Sicherheitsvorfall führt.

Die OWASP LLM Top 10 auf einen Blick:

• LLM01 Prompt-Injection, LLM02 Offenlegung sensibler Informationen, LLM03 Lieferkette, LLM04 Vergiftung von Daten und Modellen, LLM05 Unsachgemäße Verarbeitung von Ausgaben.
• LLM06 Übermäßige Handlungsautonomie, LLM07 Offenlegung des System-Prompts, LLM08 Schwachstellen bei Vektoren und Embeddings, LLM09 Fehlinformationen, LLM10 Unbegrenzter Verbrauch.
• Behandeln Sie sowohl die Modelausgabe als auch den System-Prompt als nicht vertrauenswürdig und nicht geheim.
• Verwenden Sie die Liste als Checkliste für die Bedrohungsmodellierung, kombinieren Sie sie mit MITRE ATLAS und NIST AI RMF und setzen Sie Defense-in-Depth über die Eingabe-, Modell-, Ausgabe- und Plattformebenen hinweg durch.