Warum es die OWASP Top 10 für LLMs gibt
Klassische Frameworks zur Anwendungssicherheit setzen eine klare Trennung zwischen Code, Daten und Kontrollfluss voraus. LLM-Anwendungen brechen diese Annahme. Ein Modell behandelt seinen System-Prompt, abgerufene Dokumente, Nutzereingaben und Tool-Ausgaben als einen einzigen Strom natürlicher Sprache und kann durch jeden davon gesteuert werden. Neue Komponenten — Vektordatenbanken, Retrieval-Pipelines, Agenten-Tool-Calls, Drittanbieter-Modellanbieter — führen Fehlermodi ein, die die ursprünglichen OWASP Top 10 für Webanwendungen nie vorhersahen.
Die OWASP Top 10 für LLM-Anwendungen wurde geschaffen, um diese Lücke zu schließen. Sie ist das Ergebnis von Beiträgen Hunderter Sicherheitspraktiker, AI-Forscher und Branchenteilnehmer und als Awareness-Dokument gedacht — ein priorisierter Ausgangspunkt für die Bedrohungsmodellierung, kein erschöpfender Standard und keine Zertifizierungs-Checkliste. Ihr Wert liegt darin, die Risiken konsistent zu benennen, damit Teams, die auf LLMs aufbauen, darüber kommunizieren, sie priorisieren und sie auf konkrete Kontrollen abbilden können.
Die Liste entwickelt sich von Version zu Version
Es ist wichtig, die OWASP Top 10 für LLMs als lebendiges Dokument zu behandeln. Einträge wurden zwischen Versionen umbenannt, zusammengeführt, aufgeteilt und neu eingestuft, da reale Vorfälle und agentische Architekturen die Bedrohungslandschaft verändert haben. So erweiterten spätere Überarbeitungen etwa „Model Denial of Service" hin zum breiteren Begriff des unbegrenzten Ressourcenverbrauchs und ergänzten Kategorien, die neuere Sorgen wie das Leaken von System-Prompts und Schwachstellen in Vektor- und Embedding-Pipelines widerspiegeln. Wenn Sie einen bestimmten Rang oder eine Kennung anführen (etwa einen „LLM0x"-Code), verankern Sie ihn stets in einer angegebenen Version der Liste, statt anzunehmen, dass er über Releases hinweg stabil bleibt.
Die zentralen Risikokategorien
Die folgenden Kategorien tauchen in der einen oder anderen Form über die Versionen der OWASP Top 10 für LLM-Anwendungen hinweg auf. Sie werden hier nach Thema statt nach nummeriertem Rang dargestellt.
Prompt Injection
Bösartige Anweisungen, die in Nutzereingaben oder externen Inhalten eingebettet sind, bringen das Modell dazu, seine vorgesehenen Anweisungen zu ignorieren und stattdessen dem Angreifer zu folgen. Dazu zählen direkte Injection (ein Nutzer überschreibt den System-Prompt) und indirekte Injection (Anweisungen, die in einem Dokument, einer Webseite, einer E-Mail oder einer API-Antwort verborgen sind, die das Modell später verarbeitet). In agentischen Systemen mit Tool-Zugriff gilt Prompt Injection weithin als das prägende Risiko, weil eine erfolgreiche Injection sich in reale Aktionen übersetzen kann.
Insecure Output Handling
Anwendungen, die Modell-Ausgaben ohne Validierung an nachgelagerte Systeme weitergeben, erben die Nicht-Vertrauenswürdigkeit des Modells. Wird die Antwort eines LLM als HTML gerendert, als Code ausgeführt, in einer SQL-Abfrage verwendet oder an eine Shell übergeben, wird das Modell faktisch zu einer ungeprüften Eingabequelle für klassische Injection-Schwachstellen wie XSS, SSRF oder Remote Code Execution.
Sensitive Information Disclosure
Modelle können Daten preisgeben, die sie nicht preisgeben sollten — Trainingsdaten, Geheimnisse, Inhalte anderer Nutzer oder vertrauliche Datensätze, die aus angebundenen Systemen auftauchen. Dies umfasst Daten, die über Completions abfließen, Daten, die über Retrieval-Pipelines offengelegt werden, sowie personenbezogene oder regulierte Informationen, die als Antwort auf gezielt gestaltete Prompts zurückgegeben werden.
Training Data Poisoning
Ein Angreifer manipuliert die Daten, die zum Trainieren oder Feinabstimmen eines Modells verwendet werden, und schleust Backdoors, Verzerrungen oder Schwachstellen ein. Da Trainingsdaten oft in großem Umfang aus öffentlichen oder teilweise vertrauenswürdigen Quellen stammen, kann Poisoning schwer zu erkennen sein und bleibt nach der Bereitstellung im Verhalten des Modells bestehen.
Supply Chain Vulnerabilities
LLM-Anwendungen hängen von vortrainierten Modellen, Datensätzen, Plugins, Bibliotheken und gehosteten Inferenzanbietern ab. Kompromittierte oder nicht vertrauenswürdige Komponenten an beliebiger Stelle dieser Kette — ein manipuliertes Modell-Artefakt, ein bösartiges Paket, eine verwundbare Erweiterung — können die Sicherheit der gesamten Anwendung untergraben.
Model Denial of Service / Unbounded Consumption
Gegnerische oder ressourcenintensive Eingaben können Rechenleistung, Speicher, Kontextfenster oder Token-Budgets erschöpfen und so die Verfügbarkeit beeinträchtigen oder unkontrollierte Kosten verursachen. Spätere Rahmungen dieser Kategorie betonen unbegrenzten Verbrauch in einem breiteren Sinne, einschließlich Modell-Extraktion und Kostenverstärkungs-Angriffen gegen abgerechnete Inferenz.
Excessive Agency
Wenn einem Modell mehr Funktionalität, Berechtigungen oder Autonomie eingeräumt wird, als die Aufgabe erfordert, wächst der Schadensradius eines jeden Fehlers oder einer jeden Kompromittierung entsprechend. Ein überprivilegierter Agent, der E-Mails versenden, Datensätze ändern oder externe APIs aufrufen kann, kann erheblichen Schaden anrichten, wenn er manipuliert wird — etwa per Prompt Injection.
Insecure Plugin / Extension Design
Plugins und Tool-Integrationen, die freie Eingaben akzeptieren, Autorisierungsprüfungen vermissen lassen oder Parameter nicht validieren, eröffnen Angreifern einen Weg, die vom Modell aufrufbaren Fähigkeiten zu missbrauchen. Schwaches Erweiterungsdesign ist eine häufige Brücke zwischen einem manipulierten Modell und einer realen Nebenwirkung.
Overreliance
Modell-Ausgaben ohne menschliche Aufsicht oder Überprüfung als maßgeblich zu behandeln, führt dazu, dass auf Basis halluzinierter, fehlerhafter oder unsicherer Inhalte gehandelt wird — und verbreitet fehlerhaften Code, mangelhafte Entscheidungen oder Falschinformationen in produktiven Systemen und Geschäftsprozessen.
Model Theft
Unbefugter Zugriff auf, Exfiltration oder Extraktion eines proprietären Modells — sei es durch direkten Diebstahl der Gewichte oder durch Rekonstruktion des Verhaltens mittels systematischer Abfragen — bedeutet einen Verlust geistigen Eigentums und einen möglichen Vorläufer weiterer Angriffe.
Neuere Ergänzungen
Spätere Versionen der Liste fügten Kategorien hinzu, die widerspiegeln, wie produktive LLM-Systeme tatsächlich gebaut werden. System Prompt Leakage adressiert das Risiko, dass der Inhalt eines System-Prompts — der Geheimnisse, Geschäftslogik oder Zugriffsannahmen enthalten kann — extrahiert oder als Sicherheitsgrenze herangezogen werden kann, als die er nie gedacht war. Vector and Embedding Weaknesses decken Risiken ab, die spezifisch für Retrieval-Augmented-Generation-Pipelines (RAG) sind, darunter Embedding-Inversion, Datenlecks über Mandanten hinweg und das Poisoning des Vektorspeichers.
Risikokategorien auf Gegenmaßnahmen abbilden
Keine einzelne Kontrolle deckt die gesamte Liste ab. Die Tabelle bildet mehrere repräsentative Kategorien auf die Arten von Gegenmaßnahmen ab, die sie sinnvoll reduzieren. Sie ist illustrativ, nicht erschöpfend, und die genaue Benennung und Einstufung jedes Risikos hängt von der referenzierten Version der OWASP-Liste ab.
| Risikokategorie | Repräsentative Gegenmaßnahmen |
|---|---|
| Prompt Injection | Tool-Zugriff nach Least-Privilege, Laufzeit-Aktionsvalidierung, menschliche Freigabe für risikoreiche Aktionen, Prompt-/Completion-Prüfung |
| Insecure Output Handling | Modell-Ausgaben als nicht vertrauenswürdig behandeln; vor nachgelagerter Nutzung kodieren, validieren und sandboxen |
| Sensitive Information Disclosure | Prompt- und Completion-Prüfung, Schwärzung, Datenminimierung, Mandantentrennung beim Retrieval |
| Excessive Agency | Eng gefasste Berechtigungen, per Allowlist freigegebene Tools, Autorisierung je Aktion, Governance der Agent-Runtime |
| Supply Chain Vulnerabilities | Geprüfte Modell- und Paketherkunft, Signierung, Bestandsverzeichnis von Abhängigkeiten und Artefakten |
| Unbounded Consumption / DoS | Rate Limiting, Token- und Kostenbudgets, Obergrenzen für Eingabegrößen, Anomalieerkennung bei der Nutzung |
| Overreliance | Human-in-the-Loop-Prüfung, Ausgabenverifizierung, klare Herkunfts- und Konfidenzsignale |
Das wiederkehrende Muster über diese Gegenmaßnahmen hinweg ist, dass die dauerhaftesten Kontrollen auf der Laufzeit- und Aktionsschicht wirken — indem sie regeln, worauf ein LLM oder Agent zugreifen und was es tun darf — statt sich allein auf Eingabefilterung oder bessere Prompts zu verlassen, die entschlossene Angreifer umgehen können.
Wie man die Liste in der Praxis nutzt
Die OWASP Top 10 für LLM-Anwendungen ist am nützlichsten als Eingabe für die Bedrohungsmodellierung statt als Bestanden/Nicht-bestanden-Checkliste. Ein praktischer Ansatz besteht darin, jede Stelle aufzuzählen, an der nicht vertrauenswürdige Inhalte ins Modell gelangen, jedes Tool oder System, auf das das Modell einwirken kann, und jeden nachgelagerten Konsumenten der Modell-Ausgabe — und dann jede Kategorie gegen diese Oberflächen durchzugehen, um zu erkennen, wo Kontrollen fehlen.
Da sich die Liste mit breiteren AI-Risiko-Frameworks überschneidet, lässt sie sich gut mit dem NIST AI Risk Management Framework und MITRE ATLAS für gegnerische Techniken kombinieren. OWASP benennt die Risiken; jene Frameworks helfen, Governance zu strukturieren und konkrete Angriffsmuster zu katalogisieren. Gemeinsam genutzt, geben sie Sicherheitsteams sowohl eine priorisierte Risikotaxonomie als auch den umgebenden Prozess, um sie zu steuern.
Related: Prompt Injection · AI Firewall · Data Loss Prevention (DLP)
