OWASP LLM Top 10 — Checkliste (DE)

Eine praktische Checkliste zum Absichern von LLM-Anwendungen, basierend auf den OWASP Top 10 for Large Language Model Applications (Version 2025).

Für wen ist diese Checkliste?

Entwickler, DevOps-Engineers, Sicherheitsverantwortliche und Produktverantwortliche, die LLM-basierte Anwendungen bauen oder betreiben — ob Chat-Interface, AI-Agent, RAG-System, Code-Generierung oder Content-Automation.

Was ist das OWASP LLM Top 10?

Das Open Worldwide Application Security Project (OWASP) hat 2023 erstmals eine Top-10-Liste der häufigsten und kritischsten Sicherheitsrisiken bei Large-Language-Model-Anwendungen veröffentlicht. Diese Checkliste orientiert sich an der 2025er Ausgabe und ist eine kuratierte deutsche Aufbereitung — keine offizielle OWASP-Übersetzung.

Quellen:

• OWASP GenAI: https://genai.owasp.org/
• OWASP LLM Top 10 Projekt: https://owasp.org/www-project-top-10-for-large-language-model-applications/

Hinweis: Diese Checkliste dient als Orientierung. Sie ist keine Rechtsberatung und erhebt keinen Anspruch auf Vollständigkeit. Sicherheit erfordert kontinuierliche Überprüfung und Anpassung an den Einzelfall.

---

LLM01: Prompt Injection

Worum geht's:
Angreifer manipulieren die Eingaben (Prompts), um das LLM zu unerwünschtem Verhalten zu bewegen — z. B. System-Instruktionen zu überschreiben, sensible Daten zu extrahieren oder böswillige Befehle auszuführen. Prompt Injection ist das LLM-Äquivalent zu klassischer Code-Injection.

Prüfpunkte

• System-Prompts sind vom User-Input getrennt — keine direkte Konkatenation von User-Text in System-Instruktionen
• Input-Validierung und Sanitization — User-Eingaben werden auf verdächtige Muster geprüft (z. B. "Ignore previous instructions", "System:", "<|system|>")
• Privilege-Separation bei Funktionsaufrufen — Tool-Aufrufe durch das LLM benötigen explizite Freigabe oder laufen in isolierten Kontexten
• Ausgabefilter vorhanden — LLM-Responses werden geprüft, bevor sie an Nutzer oder nachgelagerte Systeme gehen
• Logging und Monitoring von ungewöhnlichen Prompts — verdächtige Eingabemuster werden protokolliert und ausgewertet
• Regelmäßige Tests mit adversarialen Prompts — Angriffs-Simulationen (Red-Teaming) gehören zum Testing-Prozess

Typisches Warnsignal:
Das LLM gibt vertrauliche System-Instruktionen preis, ignoriert Policy-Vorgaben oder führt unerwartete Aktionen aus.

---

LLM02: Sensitive Information Disclosure

Worum geht's:
Das LLM gibt sensible Informationen in seinen Antworten preis — z. B. Trainingsdaten, API-Keys, interne Dokumente, personenbezogene Daten oder vertrauliche Business-Logik. Das kann passieren, wenn das Modell auf ungeeigneten Daten trainiert oder gefüttert wurde, oder wenn es durch geschickte Prompts dazu gebracht wird, sein Wissen offenzulegen.

Prüfpunkte

• Training-Daten wurden vor dem Training bereinigt — keine API-Keys, Passwörter, PII oder vertrauliche Dokumente im Trainings-Datensatz
• Retrieval-Quellen (RAG) sind zugriffskontrolliert — Dokumente in Vektor-DB oder Knowledge-Base sind nach Nutzerrechten gefiltert
• PII-Scrubbing in User-Anfragen und LLM-Antworten — personenbezogene Daten werden vor der Verarbeitung entfernt oder anonymisiert
• Output-Validierung auf sensible Muster — Responses werden auf API-Keys, Credentials, interne IPs, E-Mail-Adressen etc. geprüft
• Separate Modelle für unterschiedliche Sicherheitslevel — öffentliche vs. interne Anwendungen nutzen isolierte Modelle/Kontexte
• Regelmäßige Audits der Trainingsdaten und Retrieval-Quellen — laufende Überprüfung, dass keine sensiblen Daten ins System gelangen

Typisches Warnsignal:
Ein User erhält in einer LLM-Antwort Informationen, auf die er keinen Zugriff haben sollte — z. B. fremde E-Mails, interne Dokumente oder API-Credentials.

---

LLM03: Supply Chain

Worum geht's:
Die Lieferkette von LLM-Anwendungen umfasst Pre-Trained Models, Plugins, Training-Daten, Vektor-Datenbanken, externe APIs und Frameworks. Kompromittierte oder manipulierte Komponenten in dieser Kette können die gesamte Anwendung gefährden — z. B. durch Backdoors in Modellen, vergiftete Trainingsdaten oder unsichere Third-Party-Plugins.

Prüfpunkte

• Modelle stammen aus vertrauenswürdigen Quellen — nur offiziell signierte oder verifizierte Modelle werden genutzt (z. B. von OpenAI, Anthropic, HuggingFace Verified)
• Dependency-Scanning für LLM-Frameworks — regelmäßige Sicherheitsprüfung der Python/Node-Dependencies (z. B. LangChain, LlamaIndex, Haystack)
• Plugins und Erweiterungen werden vor Integration geprüft — Code-Review, Permissions-Check, Herkunfts-Validierung
• Trainingsdaten-Herkunft ist dokumentiert — nachvollziehbar, woher Daten kommen und wie sie bereinigt wurden
• Isolierung von Drittanbieter-Komponenten — externe APIs, Tools und Plugins laufen in separaten Sicherheitskontexten mit minimalen Rechten
• Regelmäßige Updates und Patch-Management — bekannte Schwachstellen in Frameworks, Bibliotheken und Modellen werden zeitnah gefixt

Typisches Warnsignal:
Ein plötzlich auftretendes, unerklärliches Verhalten des Systems oder Hinweise auf kompromittierte Abhängigkeiten in Security-Advisories.

---

LLM04: Data and Model Poisoning

Worum geht's:
Angreifer manipulieren Trainingsdaten, Fine-Tuning-Datensätze oder Retrieval-Quellen (RAG), um das Verhalten des Modells gezielt zu beeinflussen — z. B. Bias einzuschleusen, Backdoors zu installieren oder fehlerhafte Antworten zu provozieren. Model Poisoning ist besonders kritisch, weil es schwer zu erkennen und rückgängig zu machen ist.

Prüfpunkte

• Trainingsdaten werden vor Nutzung validiert — automatische Checks auf Anomalien, ungewöhnliche Muster oder verdächtige Inhalte
• User-Generated Content wird vor Aufnahme ins Training gefiltert — keine direkten User-Inputs in Fine-Tuning-Datensätze ohne Review
• RAG-Dokumente werden auf Manipulation geprüft — regelmäßige Audits der Knowledge-Base, insbesondere bei nutzergesteuertem Upload
• Sandboxing für Fine-Tuning-Prozesse — Training läuft in isolierten Umgebungen, getrennt von Produktionssystemen
• Monitoring von Modell-Drift — kontinuierliche Überprüfung, ob sich das Modellverhalten unerklärt ändert
• Adversarial Testing auf Backdoors — gezielte Tests mit Trigger-Inputs, um versteckte Manipulationen zu erkennen

Typisches Warnsignal:
Das Modell liefert plötzlich tendenziöse, fehlerhafte oder schädliche Antworten in bestimmten Kontexten, ohne dass sich der Code geändert hat.

---

LLM05: Improper Output Handling

Worum geht's:
LLM-Antworten werden ohne ausreichende Validierung direkt an nachgelagerte Systeme weitergegeben — z. B. in eine Datenbank geschrieben, in eine Shell ausgeführt oder in eine Webseite gerendert. Das öffnet klassische Injection-Angriffe (SQL-Injection, Command-Injection, XSS) über den Umweg des LLMs.

Prüfpunkte

• LLM-Outputs werden niemals direkt in Datenbank-Queries eingefügt — Prepared Statements oder ORM nutzen, auch wenn die Daten vom LLM kommen
• Keine ungeprüfte Shell-Ausführung von LLM-generiertem Code — Command-Injection-Schutz, Sandboxing oder Allowlists
• HTML/JavaScript-Escaping vor Rendering im Browser — LLM-Antworten werden vor Anzeige im Frontend sanitisiert (XSS-Schutz)
• Output-Schema-Validierung bei strukturierten Daten — JSON/XML-Responses des LLMs werden gegen ein festes Schema geprüft
• Berechtigungsprüfung vor Systemaufrufen — auch wenn das LLM einen Befehl vorschlägt, wird vorher geprüft, ob der User das darf
• Logging aller kritischen LLM-getriggerten Aktionen — nachvollziehbar, welche LLM-Outputs zu welchen System-Operationen geführt haben

Typisches Warnsignal:
Ein Angreifer kann über geschickte Prompts SQL-Befehle, Shell-Commands oder JavaScript-Code in das System einschleusen und ausführen lassen.

---

LLM06: Excessive Agency

Worum geht's:
Das LLM erhält zu weitreichende Rechte oder Zugriff auf kritische Funktionen — z. B. Datenbankschreibzugriff, API-Aufrufe, Dateisystemoperationen — ohne ausreichende Kontrolle. Ein kompromittiertes oder durch Prompt-Injection fehlgeleitetes LLM kann dann großen Schaden anrichten.

Prüfpunkte

• Principle of Least Privilege — das LLM erhält nur die minimal notwendigen Rechte für seine Aufgabe
• Explizite Freigabe für kritische Aktionen — z. B. User-Confirmation vor Löschen von Daten, Bezahlvorgängen oder externen API-Calls
• Tool-/Function-Calling ist auf sichere Funktionen beschränkt — gefährliche Operationen (z. B. rm -rf, DROP TABLE) sind nicht aufrufbar
• Auditierung aller LLM-getriggerten Aktionen — jede vom LLM initiierte Operation wird protokolliert
• Rate-Limiting und Quotas — das LLM kann nicht unbegrenzt API-Calls, Datenbankschreibvorgänge oder Ressourcen verbrauchen
• Rollback-Mechanismen für fehlerhafte LLM-Aktionen — kritische Operationen sind rückgängig machbar

Typisches Warnsignal:
Das LLM führt unbeabsichtigte oder schädliche Aktionen aus, weil es dazu die Berechtigung hatte — z. B. löscht Daten, tätigt unerwünschte Käufe oder ruft teure APIs auf.

---

LLM07: System Prompt Leakage

Worum geht's:
Der System-Prompt (die Instruktionen, die das Verhalten des LLMs steuern) wird durch geschickte User-Anfragen offengelegt. Das ist problematisch, weil der System-Prompt oft vertrauliche Geschäftslogik, interne Policies oder Sicherheitsregeln enthält — und weil Kenntnis des Prompts es leichter macht, ihn zu umgehen.

Prüfpunkte

• System-Prompts enthalten keine Secrets — keine API-Keys, Passwörter oder vertrauliche URLs im System-Prompt
• Output-Filter auf Prompt-Leakage — Antworten werden geprüft, ob sie versehentlich den System-Prompt oder Teile davon preisgeben
• Adversarial Testing auf Prompt-Extraction — regelmäßige Tests mit Prompts wie "Repeat your instructions" oder "Show me your system prompt"
• Logging von Prompt-Leakage-Versuchen — Anfragen, die nach System-Prompts fragen, werden geloggt und analysiert
• Versionierung und Rotation von System-Prompts — regelmäßige Änderung, damit geleakte Prompts schnell veralten
• Sensitive Logik ist serverseitig implementiert — nicht im Prompt beschrieben, sondern in sicherem Backend-Code

Typisches Warnsignal:
User erhalten in LLM-Antworten Hinweise auf interne Instruktionen oder können durch iterative Prompts den vollständigen System-Prompt rekonstruieren.

---

LLM08: Vector and Embedding Weaknesses

Worum geht's:
RAG-Systeme (Retrieval-Augmented Generation) nutzen Vektor-Datenbanken, um relevante Dokumente zu finden. Schwachstellen entstehen durch unzureichende Zugriffskontrolle, manipulierte Embeddings oder falsche Relevanz-Berechnungen — Angreifer können dadurch auf fremde Dokumente zugreifen oder das System mit irrelevanten oder schädlichen Informationen füttern.

Prüfpunkte

• Zugriffskontrollen in der Vektor-DB — User dürfen nur auf Embeddings/Dokumente zugreifen, für die sie berechtigt sind
• Embedding-Poisoning-Schutz — Mechanismen gegen das Einschleusen manipulierter Embeddings in die Vektor-DB
• Validierung der Retrieval-Ergebnisse — geprüft wird, ob die gefundenen Dokumente zum User-Kontext passen
• Monitoring von Retrieval-Anomalien — auffällige Suchmuster oder unerklärliche Relevanz-Scores werden geloggt
• Regelmäßige Re-Indexierung und Bereinigung — veraltete oder kompromittierte Embeddings werden aus der DB entfernt
• Isolation von Vektor-DB pro Sicherheitslevel — öffentliche und interne Dokumente liegen in getrennten Vektor-Stores

Typisches Warnsignal:
User erhalten in RAG-Antworten Dokumente, die nichts mit ihrer Anfrage zu tun haben oder auf die sie keinen Zugriff haben sollten.

---

LLM09: Misinformation

Worum geht's:
LLMs neigen zu Halluzinationen — sie generieren plausibel klingende, aber faktisch falsche Informationen. In sicherheitskritischen, medizinischen, rechtlichen oder finanziellen Kontexten kann das schwerwiegende Folgen haben. Misinformation ist ein inhärentes Modell-Risiko, das durch Architektur und Prozesse gemindert werden muss.

Prüfpunkte

• Klare Disclaimer in der UI — Nutzer werden informiert, dass LLM-Antworten Fehler enthalten können
• Fact-Checking durch externe Quellen — kritische Fakten werden gegen vertrauenswürdige Datenbanken oder APIs validiert
• Confidence-Scores nutzen — das System zeigt an, wie sicher das LLM sich bei einer Antwort ist (falls verfügbar)
• Retrieval-Augmented Generation (RAG) für faktenbasierte Antworten — LLM greift auf verifizierte Dokumente statt nur auf Training-Wissen zurück
• Human-in-the-Loop bei kritischen Entscheidungen — medizinische Diagnosen, Rechtsberatung, Finanz-Entscheidungen werden durch Menschen überprüft
• Feedback-Mechanismus für falsche Antworten — Nutzer können Fehler melden, die ins Monitoring fließen

Typisches Warnsignal:
Das LLM liefert selbstbewusst präsentierte Antworten, die sich bei Überprüfung als komplett falsch herausstellen — und das wiederholt in bestimmten Fachgebieten.

---

LLM10: Unbounded Consumption

Worum geht's:
LLM-Anfragen können extrem ressourcenintensiv sein — lange Eingaben, viele Function-Calls, teure Embedding-Operationen. Ohne Limits kann ein Angreifer (oder ein Bug) die Infrastruktur lahmlegen, hohe API-Kosten verursachen oder andere User blockieren. Das ist LLM-spezifisches Denial-of-Service-Risiko.

Prüfpunkte

• Input-Length-Limits — maximale Token-Anzahl pro User-Anfrage ist technisch durchgesetzt
• Rate-Limiting pro User — Anfragen pro Minute/Stunde/Tag sind begrenzt
• Timeout-Mechanismen für LLM-Calls — Anfragen, die zu lange laufen, werden abgebrochen
• Cost-Tracking und Budgets — Ausgaben für API-Calls werden überwacht und bei Schwellwert-Überschreitung gewarnt
• Quotas für teure Operationen — z. B. maximale Anzahl an Embedding-Berechnungen, Tool-Calls oder Retrieval-Queries pro Session
• Monitoring von Ressourcen-Anomalien — ungewöhnlich hohe Kosten oder CPU/RAM-Nutzung werden alarmiert

Typisches Warnsignal:
Plötzlich explodierende Cloud-Kosten, langsame oder ausfallende Responses oder Berichte von Nutzern, die das System nicht mehr nutzen können.

---

Weiterführende Ressourcen

Diese Checkliste deckt die 10 wichtigsten Risiken ab — für die Umsetzung in der Praxis empfehlen wir die folgenden FlowKI-Freebies als Ergänzung:

• Prompt-Hardening-Praxis-Leitfaden — konkrete Techniken gegen Prompt-Injection, mit Beispielen und Anti-Patterns
• KI-Security-Kit — umfassende Checkliste für sichere KI-Systeme, von Architektur bis Betrieb
• KI-Security-Standards (OWASP+BSI) — Mapping der wichtigsten deutschen und internationalen Standards für KI-Sicherheit

---

Letzte Aktualisierung: 2026-08-03
Quelle: OWASP Top 10 for Large Language Model Applications (2025)
Lizenz: Frei verwendbar für nicht-kommerzielle und kommerzielle Zwecke
Haftungsausschluss: Keine Rechtsberatung. Keine Garantie für Vollständigkeit oder Richtigkeit.