Wie verhindert man XSS?

XSS entsteht, wenn nicht vertrauenswürdige Daten vom Browser als Code interpretiert werden. Die gesamte Präventionsstrategie folgt einem Grundsatz: Daten als Daten behalten. Der Browser wechselt ständig den Parsing-Kontext — HTML, Attribute, JavaScript, CSS, URLs — und jeder Kontext hat andere Zeichen, die ihn aufbrechen. Die Lösung ist daher keine einzelne Zauberfunktion, sondern die richtige Codierung an der richtigen Stelle.

Kontextbezogene Ausgabecodierung (die Hauptmaßnahme)

Codiere nicht vertrauenswürdige Werte am Ausgabepunkt für den spezifischen Kontext:

• HTML-Körper → HTML-Entity-Codierung (< wird zu <).
• HTML-Attribut → Attribut-Codierung und das Attribut immer in Anführungszeichen setzen.
• Innerhalb eines <script> / einer JS-Zeichenkette → JavaScript-Codierung (Unicode-Escapes).
• URL-Parameter → URL-Codierung.

Moderne Frameworks (React, Angular, Vue) escapen standardmäßig automatisch, weshalb XSS oft nur dort auftritt, wo Entwickler zu Schlupflöchern wie dangerouslySetInnerHTML oder v-html greifen.

Sichere DOM-APIs

Für clientseitiges Rendering bevorzuge textContent, setAttribute und createElement gegenüber innerHTML, document.write und eval. Wenn du wirklich reichhaltiges HTML rendern musst, lasse es durch einen geprüften Sanitizer wie DOMPurify laufen, statt einen eigenen zu schreiben.

Eingabevalidierung — hilfreich, aber nicht ausreichend

Validiere und weise offensichtlich fehlerhafte Eingaben (Zulassungslisten, Länge, Typ) an der Grenze ab. Aber Validierung allein kann XSS nicht stoppen, denn legitime Daten (ein Name mit einem < darin) müssen bei der Ausgabe trotzdem codiert werden.

Content-Security-Policy als Absicherung

Eine strenge, Nonce- oder Hash-basierte CSP, die Inline-Skripte und eval untersagt, bedeutet: Selbst wenn eine Payload durchrutscht, weigert sich der Browser, sie auszuführen. Das ist Defense in Depth, keine primäre Maßnahme.

Prüfer wollen zuerst kontextbezogene Ausgabecodierung hören, das Verständnis, dass Validierung nicht genügt, und die CSP als Absicherung eingeordnet — sowie eine benannte sichere API oder einen Sanitizer.