prompt injections.de
Glossar

Sichere Ausgabeverarbeitung

Sichere Ausgabeverarbeitung behandelt jede Modellantwort als nicht vertrauenswürdige Eingabe, bevor sie in einem Browser, einer Datenbank, einer Datei, einem Tool oder einem anderen System verwendet wird. Sie umfasst kontextbezogene Validierung, Kodierung, Sanitizing und bei Befehlen oder Datenbanken eine strikt strukturierte Übergabe statt freier Textinterpretation.1

Einordnung

Der Begriff betrifft die Stelle nach der Modellgenerierung. Eine Prompt Injection kann ein Modell dazu bringen, schädlich wirkende Inhalte zu erzeugen oder weiterzugeben; die unsichere Ausgabeverarbeitung macht daraus erst eine klassische Anwendungsschwachstelle. OWASP führt das als LLM05 und nennt mögliche Folgen wie Cross-Site Scripting, Cross-Site Request Forgery, SSRF, Privilegienausweitung und Remote Code Execution, wenn Modelloutput unzureichend geprüft an nachgelagerte Komponenten gelangt.1 Das unterscheidet den Begriff von Sandbox: Die Sandbox begrenzt die Umgebung einer Ausführung, sichere Ausgabeverarbeitung entscheidet, ob und in welcher Form Output überhaupt als Eingabe einer weiteren Komponente zugelassen wird.

Wichtig ist der Nutzungskontext. Text für eine HTML-Ansicht benötigt andere Kodierung und erlaubte Elemente als Daten für ein SQL-Statement, einen Dateipfad, eine URL oder Tool-Parameter. „Das Modell soll nur JSON liefern“ ist allein keine Sicherheitsgarantie; ein Parser und eine Schemaprüfung müssen unerwartete Felder, Typen, Längen und Zielwerte ablehnen. Auch eine Antwort, die sprachlich harmlos wirkt, kann eine unzulässige externe Referenz oder Steuerinformation enthalten. OWASP empfiehlt deshalb Validierung, kontextabhängige Ausgabe-Kodierung, parametrisierte Datenbankabfragen, Content Security Policies sowie Protokollierung.1

Dokumentiertes Beispiel

OWASP beschreibt einen Website-Zusammenfasser, der beim Lesen einer präparierten Webseite per Prompt Injection zur Aufnahme sensitiver Inhalte bewegt wird. Ohne Output-Validierung oder -Filter können diese Daten anschließend an einen vom Angreifer kontrollierten Server gelangen.1 Die MCP-Toolspezifikation konkretisiert den Grundsatz für Tool-Ökosysteme: Server sollen Tool-Eingaben validieren und Outputs sanitizen; Clients sollen Tool-Ergebnisse validieren, bevor sie diese an ein LLM weiterreichen.2 Beide Beispiele zeigen: Die Sicherheitsgrenze liegt nicht im Wortlaut der Modellantwort, sondern in ihrer technisch erlaubten Weiterverwendung.

Bedeutung für die Abwehr

Defensive Umsetzung bedeutet, Ausgabeformate vorab eng zu definieren und programmatisch zu validieren. HTML und Markdown sollten nur über einen erlaubten Renderer oder Sanitizer angezeigt, URLs gegen Protokoll- und Host-Allowlisten geprüft, Datenbankzugriffe parametrisiert und Dateipfade auf zulässige Bereiche beschränkt werden. Tool-Aufrufe benötigen erwartete Schemas, Wertebereiche und serverseitige Autorisierung. Nicht vertrauenswürdige Modellinhalte dürfen keine automatische Netzwerkaktion, Skriptausführung oder Rechteausweitung auslösen. Diese Maßnahmen funktionieren auch dann, wenn Prompt Injection nicht sicher erkannt wird, weil sie den Übergang von Text zu Wirkung kontrollieren. Sie sind damit Grundhygiene jeder LLM-Integration, nicht ein optionaler Spezialschutz.

Quellen

  1. OWASP Foundation, „LLM10:2026 Improper Output Handling“, 3. August 2026, https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/. ↩
  2. Model Context Protocol Contributors, „Tools“, 28. Juli 2026, https://modelcontextprotocol.io/specification/2026-07-28/server/tools. ↩

Im Zusammenhang