Im Jahr 2019 waren fast 75% der großen Unternehmen von Cross-Site-Scripting betroffen. Sieben Jahre später ist XSS immer noch präsent. Microsoft meldete allein seit Januar 2024 970 geschlossene XSS-Fälle, und eine Schwachstelle aus dem Jahr 2025 im LiteSpeed Cache Plugin brachte 7 Millionen WordPress-Seiten in Gefahr.

Das Problem ist nicht die Technologie. JavaScript, die Sprache des interaktiven Webs, treibt jedes Theme, jedes Kommentarformular, jeden Warenkorb an. Das Problem besteht darin, dass ein Angreifer Ihre Seite zwingen kann, seinen Code auszuführen, und der Browser ein bösartiges Skript nicht von einem legitimen unterscheiden kann.

Lassen Sie uns die XSS-Mechanik, drei Angriffsarten und spezifische Schutzebenen aufschlüsseln, die Ihre Seite vor Cross-Site-Scripting abschirmen. Mit Tools, Codebeispielen und realen WordPress-Fällen.

💡 Kurzüberblick:

• Was XSS ist und wie ein Angreifer Schadcode in eine vertrauenswürdige Seite einschleust
• Drei Arten von Cross-Site-Scripting (gespeichert, reflektiert und DOM-basiert) und worin sie sich unterscheiden
• Schritt-für-Schritt-Einrichtung von drei Schutzebenen: WAF, Output-Escaping und Content Security Policy
• Wo Sie auf Ihrer Seite nach XSS-Schwachstellen suchen sollten und was zu tun ist, wenn ein Angriff bereits stattgefunden hat

Was ist Cross-Site-Scripting

Cross-Site-Scripting ist ein Injection-Angriff, bei dem ein Angreifer ein bösartiges Skript in eine Seite einer vertrauenswürdigen Website einbettet. Der Browser des Opfers führt diesen Code aus, weil er ihn als Teil der legitimen Seite behandelt. Daher der Name: Das Skript kommt über die Seitengrenze hinweg.

Technisch ist der Angriffsvektor nicht auf JavaScript beschränkt. Schwachstellen sind in HTML, Flash, ActiveX und CSS möglich. In der Praxis zielt die überwiegende Mehrheit der Exploits jedoch auf JS ab. Der Grund: der Zugriff auf den DOM-Baum, Cookies, localStorage und die Möglichkeit, Anfragen im Namen des Nutzers zu stellen.

Bei WordPress entstehen Schwachstellen fast immer durch Plugins und Themes, die Benutzereingaben unsachgemäß verarbeiten. Kommentarformulare, Suchleisten, Kontaktformulare, Login-Seiten: Jedes Feld, das Daten entgegennimmt und ungefiltert wieder ausgibt, wird zum Einstiegspunkt. Laut Claranet wurden 2024 in getesteten Webanwendungen 2570 Fälle von reflektiertem und gespeichertem XSS gefunden.

Wie XSS funktioniert

Ein Angreifer benötigt zwei Voraussetzungen: einen Einstiegspunkt für Schadcode und keine Filterung bei der Ausgabe. In der Praxis wird dies auf zwei Wegen erreicht: durch Manipulation von Benutzereingaben und durch Umgehung der Same-Origin-Policy.

Injection über Benutzereingaben

Das häufigste Szenario. Ein Benutzerfeld (Suchleiste, Kommentarformular, Datei-Upload-Feld) akzeptiert nicht nur Text, sondern auch ausführbaren Code. Wenn das Plugin oder Theme die Ausgabe nicht escaped, wird ein eingegebenes <script>alert('XSS')</script> im Browser jedes Nutzers ausgeführt, der die Seite öffnet.

Das Problem reicht tiefer, als es scheint. Selbst erfahrene Entwickler übersehen XSS-Vektoren über scheinbar harmlose Felder: das Hochladen einer SVG-Datei mit eingebettetem Skript, die Eingabe von Daten im Feld „Benutzername" bei der Registrierung, URL-Parameter bei Weiterleitungen. Ein Feld ohne esc_url() oder esc_attr(), und die Seite ist angreifbar.

In einer idealen Welt akzeptiert ein Suchfeld reinen Text und sonst nichts. Im realen WordPress-Ökosystem mit über 60.000 Plugins ist diese Garantie unerreichbar: Ein Plugin mit echo $_GET['q'] ohne esc_html() genügt.

Umgehung der Same-Origin-Policy

Die Same-Origin-Policy ist eine grundlegende Browsersicherheitsregel: Skripte einer Herkunft können keine Daten einer anderen Herkunft lesen. Eine Facebook-Seite und eine Bankseite, die im selben Browser geöffnet sind, tauschen keine Informationen aus. Diese Regel hat jedoch eine Achillesferse: Session-Cookies.

Wenn Sie sich bei einer Seite anmelden, erstellt der Browser ein Session-Cookie, das Ihre Identität bei jeder Anfrage bestätigt. Ohne dieses müssten Sie bei jedem Aufruf einer neuen Seite Ihr Passwort eingeben. Das Problem: Der Browser hängt dieses Cookie an jede Anfrage an die Domain an, auch an Anfragen, die von einem bösartigen Skript initiiert werden.

Angriffsschema: Ein Angreifer findet eine XSS-Schwachstelle auf example.com → schleust ein Skript ein, das document.cookie ausliest → sendet das Session-Cookie an seinen Server. Ergebnis: voller Zugriff auf das Konto des Opfers ohne Kenntnis des Passworts. Session-Cookies speichern Anmeldedaten, Warenkorbinhalte, Versandinformationen: den gesamten Nutzerkontext.

Drei Arten von XSS-Angriffen

Die Klassifizierung von XSS basiert darauf, wo und wie der Schadcode das Opfer erreicht. Es gibt drei Typen, und der Schutz Ihrer Website setzt voraus, dass Sie die Funktionsweise jedes einzelnen verstehen.

Stored XSS (Typ I)

Der gefährlichste Typ. Das schädliche Skript wird auf dem Server gespeichert (in der Datenbank, in Logs, in einem Kommentarfeld) und bei jedem Öffnen der infizierten Seite ausgeführt. Bei WordPress ist das ein klassisches Szenario: Ein Angreifer hinterlässt einen Kommentar mit einem <script>-Tag, das Kommentar-Plugin filtert kein HTML, und das Skript wird bei jedem Besucher des Beitrags ausgelöst.

Die Besonderheit von Stored XSS besteht darin, dass der Angriff nicht über einen Phishing-Link aktiviert werden muss. Das Opfer besucht lediglich die Seite. Im Jahr 2025 war die Schwachstelle CVE-2025-12709 im Interactions-Plugin für WordPress ein klassisches Stored XSS aufgrund unzureichender Eingabebereinigung in Event-Selektoren.

Reflected XSS (Typ II)

Der Angreifer sendet dem Opfer einen Link, der Schadcode in URL-Parametern enthält. Der Server „spiegelt" diesen Code in der Antwort zurück, beispielsweise in einer Suchfehlermeldung oder in der Zeile „Sie suchten nach: X." Der Browser führt das Skript aus, weil es im Antworttext von einem vertrauenswürdigen Server kam.

Reflected XSS erfordert eine aktive Handlung des Opfers: das Klicken auf einen Link. Daher wird der Angriff oft als legitime URL in einer Phishing-E-Mail getarnt. Bei WordPress ist ein typischer Vektor Such-Plugins, die die Suchanfrage ohne esc_html() ausgeben.

DOM-basiertes XSS (Typ 0)

Anders als bei den ersten beiden liegt die Schwachstelle hier nicht im serverseitigen Code, sondern im clientseitigen JavaScript. Schädliche Daten gelangen nie zum Server; sie werden direkt im Browser durch unsichere DOM-API-Methoden wie innerHTML, document.write() oder eval() verarbeitet.

Die Datenquelle ist die URL (via window.location), document.referrer oder eine andere kontrollierbare Quelle auf dem Client. Server-Logs sind sauber; der Angriff ist nur im Browser sichtbar. Dieses XSS ist am schwierigsten zu erkennen, da WAF und serverseitige Scanner es nicht sehen.

Warum XSS für WordPress besonders gefährlich ist

WordPress ist aus einem Grund das Hauptziel für XSS: das Ökosystem. Von den über 60.000 Plugins im Repository durchlaufen nicht alle eine strenge Prüfung auf Output-Escaping. Ein Plugin mit einer Schwachstelle kompromittiert die gesamte Website.

Im September 2025 veröffentlichte Microsoft eine Analyse, warum XSS 25 Jahre nach seinem Auftreten eine Bedrohung bleibt. Die Kernaussage: Die Komplexität des modernen Web-Stacks macht eine vollständige Eliminierung von XSS nahezu unmöglich, zu viele Schichten, in denen Escaping übersehen werden kann.

Was ein Angreifer durch XSS bei WordPress erlangt:

• Zugang zum Admin-Panel durch Diebstahl von Administrator-Session-Cookies
• Einschleusen versteckter Links (SEO-Spam)
• Herunterladen von Schadsoftware auf Besucherrechner
• Austausch von Zahlungsdetails in WooCommerce
• Massenhafte Verunstaltung von Seiten der Website

In Kombination mit Social Engineering wird XSS zum Vektor für ausgefeilte Angriffe: von der Installation von Keyloggern bis hin zu Cross-Site-Request-Forgery.

So schützen Sie Ihre Website vor XSS: drei Schutzebenen

XSS-Schutz erreicht man nicht mit einer einzelnen Einstellung. Nur mehrstufige Verteidigung funktioniert: Sicherheits-Plugins blockieren grobe Angriffe, Output-Escaping schließt technische Vektoren, und die Content Security Policy unterbindet die Skriptausführung auf Browserebene.

Ebene 1: Sicherheits-Plugins und Firewall

Die erste Verteidigungslinie ist ein WordPress-Plugin mit einer Web Application Firewall. Die WAF filtert eingehende Anfragen, bevor sie den Plugin-Code erreichen, und blockiert bekannte XSS-Angriffssignaturen.

Nutzen Sie bei der Auswahl eines Sicherheits-Plugins diese Checkliste:

• Regelmäßiges Scannen auf Malware und bekannte CVEs in installierten Plugins
• Firewall mit Regeln, die XSS-Muster in Anfragen blockieren
• WordPress-Hardening: XML-RPC deaktivieren, Tabellenpräfix ändern, Dateibearbeitung aus dem Admin-Bereich unterbinden
• Zentrales Update-Management für alle Plugins und Themes
• Backup, damit Sie die Website wiederherstellen können, falls ein Angriff doch durchkommt

Eine Auswahl an WordPress-Sicherheits-Plugins mit detaillierten Funktionsübersichten der einzelnen Tools finden Sie in spezialisierten Reviews auf unserer Website.

Ebene 2: Validierung und Output-Escaping

Dies ist die zentrale technische Verteidigungslinie. Die Regel ist einfach und nicht verhandelbar: Keine Nutzerdaten gelangen ohne Escaping in die Browser-Ausgabe. WordPress stellt dafür eingebaute Funktionen bereit, und jede ist an einen bestimmten Ausgabekontext gebunden.

Grundausstattung für WordPress-Entwickler:

1
// For output inside HTML tags — between <p> and </p>
2
echo esc_html($user_input);
3
 
4
// For HTML attributes — inside value="..."
5
echo esc_attr($user_input);
6
 
7
// For URLs in href, src, and other attributes
8
echo esc_url($user_url);
9
 
10
// For output inside <textarea>
11
echo esc_textarea($user_text);
12
 
13
// For JavaScript variables
14
echo esc_js($user_data);
15
 
16
// For allowed HTML tags with dangerous attributes removed
17
echo wp_kses_post($user_html);

Der entscheidende Punkt: Die Funktionswahl hängt vom Kontext ab. esc_html() in einem href-Attribut rettet Sie nicht; der Angreifer fügt javascript:alert('XSS') ein. Umgekehrt lässt esc_url() innerhalb eines Absatzes einen <script>-Tag durch. Der Kontext bestimmt die Funktion.

wp_kses() verdient besondere Erwähnung: ein leistungsfähiger Filter, der nur erlaubte HTML-Tags und -Attribute zulässt. Für Nutzerinhalte (Kommentare, Profilbeschreibungen, benutzerdefinierte Felder) ist dies das mindestens erforderliche Filterniveau.

Ebene 3: Content Security Policy (CSP)

CSP ist ein HTTP-Header, der dem Browser sagt: „Führe Skripte nur von diesen Quellen aus." Dies ist die letzte Verteidigungslinie. Selbst wenn ein Angreifer ein <script> in die Seite eingeschleust hat, führt der Browser es nicht aus, weil Inline-Skripte nicht auf der Whitelist stehen.

Basis-CSP-Richtlinie für WordPress:

1
// In functions.php or via a plugin
2
function add_csp_header() {
3
    header("Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;");
4
}
5
add_action('send_headers', 'add_csp_header');

Eine strikte Richtlinie ('strict-dynamic' statt 'unsafe-inline') ist sicherer, erfordert aber die Konfiguration von Nonce oder Hashes für jedes legitime Skript. Das ist bei einer Website mit einem Dutzend aktiver Plugins erhebliche Arbeit. Beginnen Sie mit dem Report-Only-Modus, um Verstoßprotokolle zu sammeln, ohne das Frontend zu beeinträchtigen:

1
Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report-endpoint

CSP ersetzt kein Escaping. Es mildert die Folgen von Fehlern, wenn irgendwo ein Escaping vergessen wurde.

Video: XSS von den Grundlagen bis zur Ausnutzung

Um XSS in Aktion zu sehen und zu verstehen, wie man Schwachstellen auf echten Websites findet, sehen Sie sich diese 30-minütige Analyse an:

Kehren Sie danach zu den obigen Schutzebenen zurück. Jetzt werden sie für Sie auf mechanischer Ebene Sinn ergeben, nicht nur auf der Ebene von Funktionsnamen.

⁉️🤔 Häufig gestellte Fragen

Hilft das Aktualisieren von WordPress und Plugins beim Schutz vor XSS?

Ja, und das ist der am meisten unterschätzte Schutzschritt. Jede neue Plugin-Version schließt oft spezifische CVEs, einschließlich XSS-Schwachstellen. Die LiteSpeed-Cache-Schwachstelle CVE-2025-12450 wurde innerhalb einer Woche nach Entdeckung gepatcht, aber 7 Millionen Websites, die nicht aktualisiert hatten, blieben angreifbar. Aktivieren Sie automatische Updates für alle Plugins; Kompatibilitätsprobleme sind selten, ein verpasster Patch trifft Sie dagegen garantiert.

Reicht ein Sicherheits-Plugin aus, um sich vor XSS zu schützen?

Nein. Ein Sicherheits-Plugin mit WAF schließt bekannte Angriffssignaturen, erkennt aber keine Zero-Day-Schwachstellen und nicht-standardmäßige Vektoren. Es sollte die erste Ebene sein, gefolgt von Output-Escaping im Theme-Code und CSP-Headern. Drei Ebenen zusammen bieten Schutz, den keine von ihnen allein bieten kann.

Wie prüfe ich, ob meine Website XSS-Schwachstellen hat?

Beginnen Sie mit einem kostenlosen Scanner: WPScan, Sucuri SiteCheck, Qualys SSL Labs. Für tiefergehende Tests führen Sie OWASP ZAP (Zed Attack Proxy) aus, ein Open-Source-Tool, das Eingabefelder automatisch fuzzed und reflektiertes XSS erkennt. Wichtig: Automatisierte Scanner sehen kein DOM-basiertes XSS; das erfordert ein manuelles Audit des JavaScript-Codes der Website.

Kann man XSS auf einer großen Website vollständig beseitigen?

Die vollständige Beseitigung von XSS auf einer Website mit Dutzenden Plugins und einem eigenen Theme ist eine Aufgabe nahe am Ideal, aber schwer vollständig zu erreichen. Jedes neue Plugin, jedes Theme-Update, jeder benutzerdefinierte Snippet in functions.php ist ein potenzieller Eintrittspunkt. Ein realistisches Ziel: drei Schutzebenen, automatische Updates, vierteljährliche Audits und CSP im Report-Only-Modus. So fangen Sie die allermeisten Angriffe in einem frühen Stadium ab.

Was soll ich tun, wenn meine Website bereits über XSS angegriffen wurde?

Ändern Sie sofort alle Passwörter und setzen Sie die Session-Keys in wp-config.php mit dem WordPress-Generator zurück. Stellen Sie die Website dann aus einem sauberen Backup wieder her. Installieren Sie nach der Wiederherstellung ein Sicherheits-Plugin, aktualisieren Sie alle Plugins und Themes auf die neuesten Versionen und fügen Sie einen CSP-Header in functions.php hinzu. Passwörter müssen geändert werden, weil XSS häufig Administrator-Session-Cookies stiehlt.

Sind XSS und SQL-Injection dasselbe?

Nein, obwohl beides Injection-Angriffe sind. SQL-Injection zielt über eine SQL-Abfrage auf die Datenbank; der Angreifer kann Tabellen lesen, verändern oder löschen. XSS zielt über JavaScript auf den Browser des Nutzers; das Ziel ist es, Sessions zu stehlen, Phishing-Formulare anzuzeigen oder Seiteninhalte zu verändern. Sie haben unterschiedliche Vektoren, unterschiedliche Schutzfunktionen ($wpdb->prepare() für SQL, esc_html() für XSS) und unterschiedliche Konsequenzen. In der Praxis treten sie aber oft gemeinsam auf: XSS wird genutzt, um SQL-Injection über das Admin-Panel einzuschleusen.

Muss man 2026 Angst vor XSS haben

XSS ist nicht verschwunden, aber die Abwehr dagegen ist zur technischen Routine geworden, nicht zu Magie. Drei Ebenen (ein Plugin mit WAF, Output-Escaping an allen Kontaktpunkten zum Nutzer und ein CSP-Header) schließen die allermeisten Vektoren. Dazu automatische Updates für Plugins und Themes, damit Patches ankommen, bevor Exploits greifen.

Wenn Sie derzeit keine dieser Ebenen nutzen, beginnen Sie mit der Installation eines Sicherheits-Plugins und der Aktivierung automatischer Updates im WordPress-Admin. Das dauert 10 Minuten und schließt die gröbsten Eintrittspunkte. Kehren Sie dann zu diesem Artikel zurück, wenn Sie bereit sind, Escaping und CSP zu implementieren.