XSS Schutz und Output Encoding in PHP

1. Warum ein einziger Filter für XSS Schutz nicht reicht

XSS Schutz wird in vielen PHP-Codebasen auf einen einzigen Aufruf von htmlspecialchars() reduziert, egal wo der Wert im HTML-Dokument landet. Das funktioniert im HTML-Body zuverlässig, versagt aber in anderen Ausgabekontexten wie einem HTML-Attribut ohne Anführungszeichen, einem JavaScript-String oder einer URL. Wirksamer XSS Schutz bedeutet deshalb immer, den konkreten Ausgabekontext zu kennen und die passende Escaping-Funktion für genau diesen Kontext zu wählen, statt eine einzige Funktion überall anzuwenden.

Cross-Site-Scripting entsteht, wenn nutzergesteuerte Daten so in eine Seite eingefügt werden, dass der Browser sie als Code statt als Daten interpretiert. Die Ursache liegt fast immer nicht im fehlenden XSS Schutz an sich, sondern in einer falschen Annahme über den Ausgabekontext. Ein Wert, der sicher für den HTML-Body escaped wurde, kann in einem onclick-Attribut trotzdem eine Ausführung von Skriptcode ermöglichen, weil dort andere Zeichen kritisch sind.

2. Output Encoding im HTML-Body richtig einsetzen

Für Text, der direkt zwischen HTML-Tags ausgegeben wird, ist htmlspecialchars() mit den Flags ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML5 die Basis jedes soliden XSS Schutz-Konzepts. ENT_QUOTES stellt sicher, dass sowohl doppelte als auch einfache Anführungszeichen kodiert werden, was bei späterer Wiederverwendung des Werts in einem Attribut relevant wird. ENT_SUBSTITUTE ersetzt ungültige UTF-8-Sequenzen durch ein Ersatzzeichen statt die Funktion mit einer leeren Zeichenkette abbrechen zu lassen, was sonst ein potenzielles Denial-of-Service-Risiko wäre.

Wichtig für konsistenten XSS Schutz: Die Zeichenkodierung muss explizit als dritter Parameter angegeben werden, sobald die Anwendung mit einer anderen Kodierung als UTF-8 arbeitet, sonst können ältere Encoding-Bugs im Zusammenspiel mit Multi-Byte-Zeichen entstehen. In modernen PHP-Versionen ist UTF-8 der Standard, was das Risiko reduziert, aber Legacy-Systeme mit ISO-8859-1 sollten die Kodierung immer explizit setzen.

<?php

declare(strict_types=1);

/**
 * Escape a value for safe placement inside an HTML text node.
 */
function escapeHtml(string $value): string
{
    return htmlspecialchars($value, ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML5, 'UTF-8');
}

$comment = $_POST['comment'] ?? '';

// Safe: user input is treated strictly as text, not markup
echo '<p>' . escapeHtml($comment) . '</p>';

// Unsafe: raw interpolation lets any injected <script> tag execute
// echo '<p>' . $comment . '</p>';

3. HTML-Attribute: der häufigste Encoding-Fehler

Der häufigste Fehler beim XSS Schutz passiert in HTML-Attributen ohne Anführungszeichen. <div data-id=> ohne umschließende Anführungszeichen erlaubt einem Angreifer, mit einem Leerzeichen ein neues Attribut wie onmouseover=alert(1) einzuschleusen, selbst wenn htmlspecialchars() angewendet wurde, weil Leerzeichen von der Funktion nicht als kritisches Zeichen behandelt werden. Die zuverlässige Regel für XSS Schutz in Attributen lautet deshalb: Attributwerte immer in doppelte Anführungszeichen setzen, niemals ungequotet lassen.

Selbst mit korrekten Anführungszeichen bleibt htmlspecialchars() mit ENT_QUOTES die richtige Wahl für Attributwerte, weil sowohl einfache als auch doppelte Anführungszeichen kodiert werden müssen, unabhängig davon, welchen Anführungszeichen-Typ das Template tatsächlich verwendet. Fehlt ENT_QUOTES und wird versehentlich mit einfachen Anführungszeichen gearbeitet, bleibt eine Lücke für XSS Schutz-Umgehungen offen, die in Code-Reviews leicht übersehen wird.

<?php

declare(strict_types=1);

$productId = $_GET['id'] ?? '';
$safe = htmlspecialchars($productId, ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML5, 'UTF-8');

// Safe: quoted attribute, ENT_QUOTES covers both quote styles
echo '<div data-product-id="' . $safe . '">';

// Unsafe: unquoted attribute — a space injects a new attribute like onmouseover
// echo '<div data-product-id=' . $safe . '>';

4. JavaScript-Kontext: warum htmlspecialchars nicht ausreicht

Wird ein PHP-Wert direkt in einen Inline-<script>-Block eingefügt, reicht htmlspecialchars() für vollständigen XSS Schutz nicht aus, weil JavaScript-Strings andere Sonderzeichen kennen als HTML. Ein Wert wie ');alert(1);// würde von htmlspecialchars() unverändert durchgelassen, weil weder Anführungszeichen im JavaScript-Sinn noch Semikolons zu den kodierten HTML-Zeichen gehören. Der korrekte Weg für XSS Schutz in diesem Kontext ist, den Wert über json_encode() zu serialisieren, was automatisch alle für JavaScript-Strings kritischen Zeichen korrekt escaped.

Zusätzlich sollte json_encode() mit den Flags JSON_HEX_TAG | JSON_HEX_APOS | JSON_HEX_QUOT | JSON_HEX_AMP aufgerufen werden, wenn der resultierende Wert innerhalb eines HTML-<script>-Tags landet, damit ein enthaltenes </script> im Wert nicht das umschließende Tag vorzeitig beendet. Ohne diese Flags kann ein Angreifer mit dem String </script><script>alert(1)</script> den XSS Schutz aushebeln, selbst wenn json_encode() ohne die zusätzlichen Flags verwendet wurde.

<?php

declare(strict_types=1);

$userName = $_GET['name'] ?? '';

// Safe: proper JSON encoding with HTML-context-aware flags
$jsonSafe = json_encode(
    $userName,
    JSON_HEX_TAG | JSON_HEX_APOS | JSON_HEX_QUOT | JSON_HEX_AMP | JSON_THROW_ON_ERROR
);

echo '<script>const userName = ' . $jsonSafe . ';</script>';

// Unsafe: htmlspecialchars() does not escape JS-critical characters
// echo '<script>const userName = "' . htmlspecialchars($userName) . '";</script>';

5. URL-Kontext: rawurlencode statt manueller Filter

Werden Werte in eine URL eingebettet, etwa als Query-Parameter oder Teil eines Pfads, ist rawurlencode() die richtige Funktion für XSS Schutz in diesem Kontext, nicht htmlspecialchars(). rawurlencode() kodiert nach RFC 3986 und behandelt Sonderzeichen wie &, = und Leerzeichen korrekt, die sonst die URL-Struktur selbst verändern oder zusätzliche Parameter einschleusen könnten. Wichtig ist zusätzlich, das Schema eines nutzergesteuerten URL-Werts zu prüfen: Ein javascript:-Schema in einem href-Attribut umgeht jedes Encoding, weil es syntaktisch gültig bleibt und dennoch Skriptcode ausführt.

Für vollständigen XSS Schutz bei nutzergesteuerten URLs empfiehlt sich eine Allowlist erlaubter Schemata, typischerweise https und mailto, bevor der Wert überhaupt in ein Attribut eingesetzt wird. Ein Wert, der nicht mit einem erlaubten Schema beginnt, sollte entweder verworfen oder auf einen sicheren Standardwert zurückgesetzt werden, statt ihn blind zu kodieren und auszugeben.

<?php

declare(strict_types=1);

/**
 * Validate and encode a user-supplied URL for safe use in an href attribute.
 */
function safeHref(string $url): string
{
    $allowedSchemes = ['https', 'mailto'];
    $parsed = parse_url($url);

    if (!isset($parsed['scheme']) || !in_array(strtolower($parsed['scheme']), $allowedSchemes, true)) {
        return '#'; // Reject javascript:, data:, and unknown schemes outright
    }

    return htmlspecialchars($url, ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML5, 'UTF-8');
}

$profileLink = $_GET['link'] ?? '';
echo '<a href="' . safeHref($profileLink) . '">Profil</a>';

6. DOM-based XSS: wenn der Server gar nicht beteiligt ist

Nicht jede XSS-Lücke entsteht serverseitig. DOM-based XSS tritt auf, wenn clientseitiges JavaScript einen kontrollierbaren Wert, etwa aus location.hash oder document.referrer, ungeprüft in innerHTML oder eine ähnliche gefährliche Senke schreibt, ohne dass ein PHP-Server jemals mit diesem Wert in Berührung kommt. Serverseitiger XSS Schutz mit htmlspecialchars() hat auf DOM-based XSS keinen Einfluss, weil der problematische Datenfluss vollständig im Browser stattfindet.

Für PHP-Anwendungen mit ausgeliefertem JavaScript bedeutet das: Die serverseitigen Escaping-Regeln aus diesem Artikel schützen nicht automatisch vor DOM-based XSS in eigenem Frontend-Code. Hyvä-Themes und Alpine.js-Komponenten, die mit x-html statt x-text arbeiten, sollten deshalb besonders sorgfältig geprüft werden, welche Werte tatsächlich als Markup statt als reiner Text gerendert werden, und ob diese Werte aus einer vertrauenswürdigen, serverseitig bereits escapten Quelle stammen.

7. Templates und automatisches Escaping

Moderne Template-Engines wie Twig oder Blade bieten automatisches Escaping als Standardverhalten, was einen großen Teil des manuellen XSS Schutz-Aufwands eliminiert. Jeder Ausdruck in {{ variable }} wird automatisch für den HTML-Body-Kontext escaped, ohne dass Entwickler daran denken müssen. Das Risiko verschiebt sich dadurch auf die explizite Deaktivierung des Escapings, etwa über {{ variable|raw }} in Twig, die bewusst und selten eingesetzt werden sollte, ausschließlich für Werte, die nachweislich aus vertrauenswürdigen Quellen stammen.

In reinem PHP ohne Template-Engine bleibt XSS Schutz Entwickler-Verantwortung bei jeder einzelnen Ausgabe. Eine praktikable Zwischenlösung ist eine kleine Helper-Klasse mit kontextspezifischen Methoden wie e() für HTML, eAttr() für Attribute und eJs() für JavaScript, die im Template konsequent statt der rohen Variable verwendet werden und so das Risiko vergessenen Escapings deutlich reduzieren.

8. Typische Fehler beim Output Encoding

Der häufigste Fehler ist, htmlspecialchars() ohne ENT_QUOTES aufzurufen und sich dann auf den vermeintlichen XSS Schutz in einem einfach gequoteten Attribut zu verlassen. Ohne dieses Flag werden nur doppelte Anführungszeichen kodiert, ein einfaches Anführungszeichen im Attributwert kann das Attribut vorzeitig beenden. Ein zweiter Fehler ist doppeltes Escaping, bei dem ein bereits escapter Wert ein zweites Mal durch htmlspecialchars() geschickt wird, was zu sichtbaren HTML-Entities wie < statt korrekt gerenderten Zeichen führt.

Ein dritter, subtilerer Fehler betrifft die Verwechslung von Escaping mit Validierung. XSS Schutz durch Output Encoding verhindert, dass ein Wert als Code interpretiert wird, sagt aber nichts darüber aus, ob der Wert inhaltlich sinnvoll oder erwartet ist. Eine E-Mail-Adresse sollte zusätzlich zum Escaping auch validiert werden, weil Escaping allein eine fachlich fehlerhafte Eingabe klaglos durchlässt, solange sie technisch keine Skriptausführung ermöglicht.

9. Escaping-Funktionen im direkten Vergleich

Die Wahl der richtigen Escaping-Funktion hängt vollständig vom Ausgabekontext ab. Die folgende Übersicht ordnet die wichtigsten PHP-Funktionen für XSS Schutz ihrem jeweiligen Kontext zu.

Wer diese Tabelle konsequent anwendet, deckt die überwältigende Mehrheit realer XSS-Angriffsvektoren ab. Der XSS Schutz einer Anwendung ist immer nur so stark wie der schwächste, falsch behandelte Ausgabekontext.

10. Zusammenfassung

Wirksamer XSS Schutz in PHP ist kein einzelner Funktionsaufruf, sondern eine Entscheidung pro Ausgabekontext: htmlspecialchars() mit ENT_QUOTES für HTML-Body und gequotete Attribute, json_encode() mit HEX-Flags für JavaScript-Strings, rawurlencode() plus Schema-Allowlist für URLs. DOM-based XSS erinnert daran, dass serverseitiges Output Encoding allein nicht ausreicht, sobald clientseitiges JavaScript Werte ungeprüft in gefährliche Senken wie innerHTML schreibt.

Der zuverlässigste Weg, XSS Schutz konsequent umzusetzen, ist eine kleine Bibliothek kontextspezifischer Escaping-Helfer, die in jedem Template statt der rohen PHP-Ausgabe verwendet wird. Template-Engines mit automatischem Escaping nehmen einen Großteil dieser Verantwortung ab, ersetzen aber nicht das Verständnis dafür, wann und warum eine bestimmte Escaping-Funktion die richtige Wahl ist.

11. FAQ: XSS Schutz und Output Encoding in PHP