Glossar · einfach erklärt

XSS (Cross-Site-Scripting)

XSS schleust fremdes JavaScript in Ihre Website ein — und läuft dann im Browser Ihrer Nutzer, mit deren Rechten.

Cross-Site-Scripting (XSS) schleust fremden Skriptcode in eine Webseite ein, der dann im Browser anderer Nutzer ausgeführt wird — mit deren Sitzung und Rechten. Möglich wird das, wenn eine Anwendung Nutzereingaben ungefiltert in ihre Seiten einbaut.

Die Folgen reichen vom Sitzungsdiebstahl über manipulierte Inhalte bis zu nachgebauten Login-Masken im echten Seitenkontext — für Nutzer praktisch nicht erkennbar, weil die Adresszeile stimmt.

Die drei XSS-Typen

Reflected XSS liefert den Schadcode über einen präparierten Link, der von der Anwendung ins Antwort-HTML gespiegelt wird. Stored XSS ist gefährlicher: Der Code wird gespeichert — etwa in Kommentaren oder Profilfeldern — und trifft jeden, der die Seite aufruft. DOM-basiertes XSS entsteht komplett im Browser, wenn client-seitiger Code Eingaben unsicher verarbeitet.

Der Kernschutz heißt konsequentes Escaping: Ausgaben werden je Kontext (HTML, Attribut, JavaScript, URL) kodiert — moderne Frameworks erledigen das weitgehend automatisch, solange man ihre Schutzmechanismen nicht umgeht. Eine Content Security Policy begrenzt zusätzlich, was eingeschleuster Code überhaupt tun könnte; die WAF filtert bekannte Muster am Rand.

Schutzschichten gegen XSS

Kontextgerechtes Output-Encoding — vom Framework erzwungen, nicht handgestrickt.
Content Security Policy als Schadensbegrenzung für den Ernstfall.
HttpOnly-Cookies: Sitzungen bleiben für Skripte unlesbar.
WAF-Regeln gegen bekannte XSS-Muster, besonders vor Altanwendungen.

Häufige Fragen zu XSS (Cross-Site-Scripting)

Was kann ein Angreifer mit XSS anrichten?

Alles, was die Seite im Browser des Opfers darf: Sitzungen übernehmen, Eingaben abgreifen, Inhalte manipulieren, im Namen des Nutzers Aktionen auslösen oder täuschend echte Login-Masken einblenden — bei korrekter Adresszeile. XSS ist deshalb weit mehr als ein Schönheitsfehler.

Worin unterscheiden sich Stored und Reflected XSS?

Reflected XSS steckt im präparierten Link und trifft nur, wer ihn anklickt. Stored XSS liegt in der Anwendung selbst — etwa in einem gespeicherten Kommentar — und trifft automatisch jeden Besucher der Seite. Gespeichertes XSS hat darum die größere Reichweite.

Schützen moderne Frameworks vor XSS?

Weitgehend: React, Vue und Co. escapen Ausgaben standardmäßig. Gefährlich wird es an den Ausbruchsstellen — Funktionen, die bewusst rohes HTML rendern, unsichere URL-Verarbeitung, Altcode daneben. Die Disziplin liegt darin, diese Ausnahmen wie Sprengstoff zu behandeln.

Was bringt eine Content Security Policy gegen XSS?

Sie ist das Sicherheitsnetz: Selbst wenn Code eingeschleust wird, begrenzt die CSP, was er darf — etwa keine fremden Skriptquellen, kein Datenversand an beliebige Ziele. Eine strenge CSP macht aus einer XSS-Lücke oft einen Fehlschlag statt eines Vorfalls.

Hilft eine WAF gegen XSS?

Als Schicht ja: Bekannte Angriffsmuster werden am Netzwerkrand geblockt, frische Lücken lassen sich virtuell patchen — wertvoll besonders vor Anwendungen, deren Code man nicht schnell ändern kann. Die Wurzelbehandlung bleibt korrektes Encoding in der Anwendung.