XSS mit innerHTML und wie Sie es verhindern

el.innerHTML = userInput interpretiert die Zeichenfolge als HTML. Enthält userInput <script>-Tags oder Event-Handler-Attribute (onclick, onerror), interpretiert der Browser diese und führt vom Angreifer kontrollierten Code auf der Seite aus.

Jeder Code, der Benutzerdaten in HTML einfügt – etwa Server-Templates oder clientseitiges Rendering –, birgt ein XSS-Risiko, wenn die Daten nicht maskiert werden. Single-Page-Apps, die innerHTML aus API-Antworten erstellen, sind besonders gefährdet, wenn diese Antworten Benutzerinhalte enthalten.

Ein Benutzername „Bob<img src=x onerror=alert(1)>“, der über div.innerHTML = `Welcome, ${user}` gesetzt wird, führt alert(1) aus, wenn das Bild nicht geladen werden kann. Dieselbe Nutzlast als reiner Text (über textContent) ist harmlos – der Browser sieht nur Zeichen und keine Tags.

textContent setzt ausschließlich Text – HTML-Sonderzeichen erscheinen als Literalzeichen und niemals als Tags. In 90 % der Fälle ist dies das richtige Werkzeug. Wechseln Sie nur dann zu innerHTML, wenn Sie tatsächlich Markup und nicht bloß Text darstellen müssen.

Um Elemente mit Benutzerdaten zu erstellen, bauen Sie sie mit createElement und textContent auf: const li = document.createElement("li"); li.textContent = name; ul.appendChild(li);. Das Ergebnis ist strukturell identisch mit innerHTML, aber von Grund auf XSS-sicher.

Für vom Server generiertes, vertrauenswürdiges HTML (Ihre eigene Template-Ausgabe oder bereinigten Rich Text aus einem vertrauenswürdigen Editor) ist innerHTML in Ordnung. Wenden Sie es niemals direkt auf Daten aus nicht vertrauenswürdigen Quellen an, ohne diese vorher zu bereinigen.

Wenn Benutzer Rich Text übermitteln (etwa in einem Kommentar-Editor oder bei der Markdown-Darstellung), bereinigen Sie ihn vor dem Setzen von innerHTML: el.innerHTML = DOMPurify.sanitize(richHtml). DOMPurify entfernt gefährliche Tags und Attribute und erhält dabei sichere Formatierungen wie <b>, <em> und <a>.

el.insertAdjacentHTML("beforeend", html) interpretiert HTML-Zeichenfolgen – mit derselben XSS-Angriffsfläche wie innerHTML. Es gelten dieselben Regeln: Übergeben Sie niemals direkt Benutzerdaten; bereinigen Sie sie oder verwenden Sie DOM-Methoden. Dasselbe gilt für document.write, obwohl das inzwischen niemand mehr verwenden sollte.

React, Vue, Svelte und Angular maskieren interpolierten Text standardmäßig – {name} ist sicher. Sie bieten Ausnahmen an (dangerouslySetInnerHTML in React und v-html in Vue), die dasselbe XSS-Risiko bergen; verwenden Sie sie sparsam und nur mit Bereinigung.

Auch Attributwerte können als Angriffsvektoren dienen: <a href={url}> mit url="javascript:alert(1)" führt den Code beim Anklicken aus. Prüfen Sie URLs nach ihrem Schema (erlauben Sie nur http:, https:, mailto: und tel:), bevor Sie Benutzereingaben in href, src oder andere URL-Attribute einsetzen.

Moderne Browser unterstützen Trusted Types: Konfigurieren Sie CSP mit require-trusted-types-for 'script', dann akzeptiert innerHTML keine rohen Zeichenfolgen mehr – nur von einer Policy umschlossene Werte werden zugelassen. Dadurch wird XSS durch die API statt durch Disziplin verhindert.

Keine einzelne Ebene reicht aus. Kombinieren Sie serverseitige Eingabevalidierung, Ausgabe-Escaping beim Rendern, CSP zum Blockieren eingeschleuster Skripte, Trusted Types zum Zurückweisen roher Zeichenfolgen und eine Sicherheitsüberprüfung jeder Verwendung von innerHTML. Eine mehrschichtige Verteidigung übersteht einen Fehler in jeder einzelnen Ebene.

Warum ist el.textContent = userInput vor XSS sicher, während el.innerHTML = userInput gefährlich ist?

innerHTML bei Benutzereingaben ist der klassische XSS-Vektor. Verwenden Sie textContent für Text, createElement+textContent für Strukturen und DOMPurify, wenn Rich-HTML erforderlich ist. Validieren Sie URL-Schemata für Attributwerte. Ergänzen Sie CSP und Trusted Types, um Fehler zu neutralisieren, die durch das Code-Review schlüpfen. Moderne Frameworks escapen standardmäßig — verwenden Sie deren unsichere Auswege selten und prüfen Sie sie.