# OWASP LLM Top 10 — Prüf-Checkliste (Deutsch) 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/](https://genai.owasp.org/) - OWASP LLM Top 10 Projekt: [https://owasp.org/www-project-top-10-for-large-language-model-applications/](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](https://flowki-club.de/freebies/prompt-hardening)** — konkrete Techniken gegen Prompt-Injection, mit Beispielen und Anti-Patterns - **[KI-Security-Kit](https://flowki-club.de/freebies/ki-security-kit)** — umfassende Checkliste für sichere KI-Systeme, von Architektur bis Betrieb - **[KI-Security-Standards (OWASP+BSI)](https://flowki-club.de/freebies/ki-security-standards)** — 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.