Ein Kommentarfeld sieht aus wie ein Feld für Text. Für den Browser ist jede Ausgabe aber erst einmal Teil der Seite, den er liest, nicht reiner Text.

Genau hier werden Eingabe und Ausgabe verwechselt. Viele prüfen, was hereinkommt, und halten die Seite dann für sicher. Ob Cross-Site Scripting (XSS) entsteht, entscheidet sich aber erst bei der Ausgabe.

Eingabefilterung prüft Daten, bevor der Server sie annimmt. Sie blockt etwa HTML-Zeichen im Kommentarfeld oder lehnt verdächtige Werte ab. Das Problem: Ein Filter kann nie alle Fälle kennen. Gibt jemand statt eines Kommentars ein script-Element mit JavaScript ein, entscheidet nicht der Filter, sondern erst die Ausgabe, ob es läuft.

Ausgabekodierung, auch Escaping genannt, greift dort, wo der Schaden entsteht. Sie ersetzt Zeichen mit Sonderbedeutung durch ungefährliche Kürzel. So wird < zu &lt;, und der Browser zeigt spitze Klammern als Text an, statt sie als Tag zu lesen.

Filterung schätzt die Eingabe ein, Kodierung entschärft die Ausgabe. Weil dieselbe Eingabe in HTML-Text, Attribut, URL oder JavaScript-String je eigene Kodierungsregeln braucht, schützt nur kontextgerechtes Escaping an jedem Ausgabeort.

„Faustregel:" Eingaben validieren, um fehlerhafte Daten abzuweisen; für Sicherheit aber jede Ausgabe im passenden Kontext kodieren. Eine Content Security Policy, die vorgibt, von wo Skripte geladen dürfen, ergänzt das als zweite Verteidigungslinie.

XSS heißt nicht, dass jemand den Server knackt, sondern dass fremdes Skript im Browser der Opfer läuft – etwa mit deren Sitzungs-Cookies. Geschlossen wird die Lücke durch Kodierung am Ausgabeort, nicht durchs Filtern allein.

📌 Eingabe prüfen · Ausgabe kodieren · Kontext beachten

📚 Webentwicklung von Grund auf · Tag 5 von 30
#WebSecurity #webdev #javascript