Improper Output Handling bei LLMs: Ausgaben sicher weiterverarbeiten

Improper Output Handling (unsichere Verarbeitung von Ausgaben) bezeichnet das Risiko, Ausgaben eines Sprachmodells ungeprüft an nachgelagerte Systeme weiterzugeben. OWASP führt den Punkt in der Fassung 2025 seiner Liste als LLM05; bis zur Fassung 2023/24 stand derselbe Eintrag als LLM02 unter dem Namen „Insecure Output Handling“. Werden LLM-Antworten ohne Validierung in Browser, Datenbanken oder Shells übernommen, drohen Angriffe wie Cross-Site-Scripting, SQL-Injection oder Remote Code Execution. Schutz bieten konsequente Ausgabevalidierung, kontextgerechtes Escaping und der Grundsatz, jede Modellausgabe als nicht vertrauenswürdige Eingabe zu behandeln.

Wo die Prüfung der Modellausgabe fehlt

Der Fehler steckt nicht im Modell, sondern in der Zeile danach. Eine Anwendung nimmt die Antwort entgegen und gibt sie an die nächste Komponente weiter, ohne sie anzusehen. Sie tut das, weil die Antwort aus dem eigenen System kommt und der Aufruf aussieht wie jeder andere im eigenen Code.

Was LLMs (große Sprachmodelle) ausgeben, hängt allerdings am Prompt, und den schreibt im Zweifel der Benutzer. LLM05 Improper Output Handling beschreibt deshalb einen indirekten Zugriff: Wer den Prompt beeinflusst, bestimmt die Zeichen, die in der nachgelagerten Komponente ankommen, und erreicht damit eine Funktion, zu der ihm die Oberfläche keinen Weg anbietet. Die Prüfung, die zwischen Formulareingabe und Verarbeitung selbstverständlich ist, fehlt hier, weil an dieser Stelle scheinbar keine Benutzereingabe steht.

Abgrenzung zu Misinformation

Der Nachbarpunkt der OWASP-Liste heißt seit der Fassung 2025 Misinformation (OWASP LLM09) und behandelt den Inhalt einer Antwort; hier geht es um ihre Weiterverarbeitung, unabhängig davon, ob der Inhalt stimmt.

Was aus einer ungeprüften Ausgabe wird

Der Schaden entsteht dort, wo die Antwort ankommt. Im Browser wird aus einem Stück Markdown ein Skript, das im Namen des angemeldeten Benutzers handelt; OWASP führt für diesen Weg Cross-Site Scripting (XSS) und Cross-Site Request Forgery (CSRF). Auf der Serverseite ruft der Server ein internes Ziel auf, weil die Ausgabe ihn dazu bringt (Server-Side Request Forgery). Am Ende dieses Wegs stehen erweiterte Rechte und fremder Code, den der Server ausführt. Die Fassung 2025 nennt sechs Bedingungen, unter denen dieser Schaden größer ausfällt:

Die Anwendung räumt dem Modell mehr Rechte ein, als sie dem Endbenutzer zugesteht. Der Zuschnitt dieser Rechte ist ein Punkt für sich und steht unter Excessive Agency (OWASP LLM06).
Die Anwendung ist anfällig für indirekte Prompt Injection (OWASP LLM01). Wer den Text kontrolliert, den das Modell nebenbei liest, bestimmt damit auch dessen Ausgabe.
Erweiterungen von Drittanbietern prüfen ihre Eingaben nicht ausreichend.
Die Ausgabe wird nicht für den Kontext kodiert, in dem sie landet (HTML, JavaScript, SQL).
Die Ausgaben des Modells werden nicht protokolliert und nicht überwacht.
Für die Nutzung des Modells gibt es weder eine Ratenbegrenzung noch eine Erkennung auffälliger Muster.

Häufige Beispiele für Schwachstellen

Die Ausgabe geht unverändert in eine Systemshell oder in eine Funktion wie exec oder eval. Damit führt der Server aus, was das Modell geschrieben hat.
Das Modell liefert JavaScript oder Markdown an den Benutzer zurück. Der Browser interpretiert es, und es entsteht XSS.
Eine vom Modell formulierte SQL-Abfrage läuft ohne Parametrisierung. Was als Wert gemeint war, liest die Datenbank als Befehl.
Aus einer Modellausgabe wird ein Dateipfad gebaut, ohne ihn zu bereinigen. Zwei Punkte an der richtigen Stelle führen aus dem vorgesehenen Verzeichnis heraus (Path Traversal).
Der erzeugte Text wandert ungeprüft in eine E-Mail-Vorlage. Empfänger bekommen dann eine Nachricht aus Ihrem Haus, deren Inhalt jemand anderer bestimmt hat.

Präventionsmaßnahmen

Alle Gegenmaßnahmen sitzen an derselben Naht, zwischen der Antwort des Modells und dem System, das sie übernimmt:

Behandeln Sie das Modell wie jeden anderen Benutzer. Zero Trust heißt an dieser Stelle: Jede Antwort, die an eine Backend-Funktion weitergeht, wird vorher geprüft.
Kodieren Sie die Ausgabe für den Kontext, in dem sie landet. Für die Webseite ist das eine HTML-Kodierung, für die Datenbankabfrage ein Escaping der Sonderzeichen.
Verwenden Sie für jede Datenbankoperation mit Modellausgabe vorbereitete Anweisungen (Prepared Statements) statt zusammengesetzter Abfragen.
Setzen Sie eine strenge Content Security Policy. Sie fängt das Skript ab, das trotz aller Prüfung in die Seite gelangt ist.
Protokollieren Sie die Ausgaben und suchen Sie darin nach auffälligen Mustern. Ein Versuch, der scheitert, sieht im Protokoll anders aus als eine beantwortete Frage.
Halten Sie sich bei Validierung und Bereinigung an den OWASP ASVS (Application Security Verification Standard). Dort steht auch die Anleitung zur Ausgabe-Kodierung.

Angriffsszenarien

Vier Fälle aus der Fassung 2025, auf den Betriebsalltag übertragen:

Ein Assistent beantwortet Kundenfragen und reicht seine Antwort an eine Erweiterung weiter, die daneben auch administrative Funktionen anbietet. Weil niemand prüft, was da weitergereicht wird, schaltet sich die Erweiterung auf ein Wort hin in den Wartungsmodus.
Ein Zusammenfassungsdienst arbeitet eine fremde Webseite ab, in der eine Anweisung an das Modell versteckt ist. Das Modell sammelt daraufhin Vertrauliches aus dem laufenden Gespräch, kodiert es und hängt es an eine Adresse, die es selbst aufruft. Zwischen dieser Ausgabe und dem Server des Angreifers steht weder ein Filter noch eine Prüfung.
Ein Chatfenster erlaubt es Mitarbeitern, sich Auswertungen aus der Datenbank zusammenstellen zu lassen. Jemand bittet um eine Abfrage, die alle Tabellen löscht. Läuft sie ungeprüft, sind die Tabellen weg.
Eine Webanwendung gibt Texte aus, die das Modell aus Benutzereingaben erzeugt hat, und bereinigt sie nicht. Ein präparierter Prompt genügt, damit eine JavaScript-Payload zurückkommt und im Browser des nächsten Lesers ausgeführt wird.

Fazit

Unter den zehn Punkten der OWASP-Liste ist dieser der handwerklichste. Er verlangt kein Wissen über Modelle, er verlangt die Frage, die in der Webentwicklung seit jeher am Anfang steht: Woher kommt dieser Text, und was geschieht als Nächstes damit? Neu ist nur die Antwort auf den ersten Teil. Der Text ist im eigenen Haus entstanden und trägt trotzdem die Handschrift dessen, der die Anfrage gestellt hat.

Häufige Fragen

Was bedeutet Improper Output Handling?

Improper Output Handling heißt: Ein nachgelagertes System übernimmt die Ausgabe eines Sprachmodells ungeprüft und reicht sie weiter. OWASP zählt ihn seit 2025 als fünften seiner zehn Punkte zu Anwendungen mit Sprachmodellen. Wird der Output ohne Validierung in eine Webseite, eine Datenbankabfrage oder in Code eingefügt, kann er Schadwirkung entfalten, vergleichbar mit klassischen Injection-Schwachstellen.

Ist eine falsche Modellausgabe dasselbe wie eine unsicher verarbeitete?

Eine falsche Auskunft und eine gefährlich weiterverarbeitete Auskunft sind zwei verschiedene Fälle, und im Ernstfall trennt sie eine einzige Frage: Hätte ein aufmerksamer Mensch den Schaden durch Lesen verhindert? Wenn ja, stand eine falsche Auskunft im Weg, und der Fall gehört zu Misinformation (OWASP LLM09). Wenn nein, weil die Ausgabe niemand gelesen hat und ein Programm sie ausgeführt hat, liegt Improper Output Handling vor. Für die Behebung entscheidet das, wer gefragt ist: einmal derjenige, der den Ablauf festlegt, einmal derjenige, der den Code schreibt, der die Antwort entgegennimmt.

Wie schützt man sich vor unsicherer Ausgabeverarbeitung?

Indem man die Ausgaben eines Sprachmodells grundsätzlich als nicht vertrauenswürdig behandelt: konsequentes Validieren, Escapen und Filtern, bevor der Output in andere Systeme übernommen wird. Mehr dazu unter Datenschutz & KI-Sicherheit.