Was ist Cross-Site Scripting (XSS)?

So funktioniert die Lücke und so schützt du dich

Cross-Site Scripting klingt nach Insiderkram aus der Hacker-Szene. Tatsächlich ist es eine der ältesten und hartnäckigsten Sicherheitslücken im Web, und sie betrifft dich öfter als du denkst. Immer dann, wenn ein Browser fremden Code ausführt, weil eine Webseite ihn unsauber durchgereicht hat, hat XSS seine Bühne.

Die gute Nachricht: Wenn du verstehst, wie XSS funktioniert, kannst du die typischen Fallen schon beim Lesen einer URL erkennen. Und du weisst, warum dein Browser dich heute deutlich besser schützt als noch vor zwanzig Jahren.

Was bedeutet „Cross-Site Scripting“?

Cross-Site Scripting, kurz XSS, ist eine Sicherheitslücke in Websites. Ein Angreifer schmuggelt fremden Code (meist JavaScript) in eine ansonsten vertrauenswürdige Seite ein. Dein Browser sieht den Code als Teil dieser Seite und führt ihn brav aus, mit allen Rechten, die diese Seite hat. Eine ausführliche Definition mit zahlreichen Code-Beispielen führt die OWASP Foundation in ihrem XSS-Eintrag.

Stell dir vor, ein Brief soll persönlich vom Absender unterschrieben sein, aber das Postamt schiebt einfach jedes Stück Papier durch, das hineingesteckt wird, samt fremder Unterschrift. Genau das passiert bei XSS auf technischer Ebene: Die Website akzeptiert Eingaben, ohne sie zu prüfen, und der Browser hält das eingeschmuggelte Skript für legitim, weil es auf der richtigen Domain liegt.

Kurz zusammengefasst: XSS ist eine Lücke, bei der eine Webseite fremden Code an deinen Browser durchreicht. Du surfst auf einer echten Seite, aber dein Browser führt heimlich das Skript eines Angreifers aus.

Wie funktioniert ein XSS-Angriff?

Im Kern braucht ein XSS-Angriff drei Zutaten:

1. Eine Webseite, die Nutzereingaben annimmt und wieder ausgibt (Suchfeld, Kommentarfunktion, URL-Parameter, Profilseite).
2. Eine Lücke, die diese Eingabe ungeprüft in den HTML-Output stellt.
3. Ein Angreifer, der die Eingabe so präpariert, dass dein Browser sie als Code interpretiert.

Ein simples Beispiel: Eine Seite zeigt deine Suche an mit „Du suchst nach: …“. Ein Angreifer baut den Suchbegriff so um, dass dort statt eines Wortes ein <script>-Tag landet. Klickst du auf den präparierten Link, lädt deine Adressleiste die echte Seite, aber der Browser sieht den Skript-Schnipsel und führt ihn aus. Cookies, Sessions, Formularinhalte: alles, was die Seite kennt, kennt jetzt auch das Skript.

Kurz zusammengefasst: Ein Angreifer baut eine manipulierte URL oder einen manipulierten Beitrag. Wer darauf klickt oder die Seite lädt, führt unfreiwillig den Code des Angreifers aus, immer mit den Rechten der eigentlichen Seite.

Welche Arten von XSS gibt es?

Sicherheitsforscher unterscheiden drei Spielarten, die sich darin unterscheiden, wo das Schadskript zwischengelagert wird.

Reflected XSS

Das Skript steckt direkt in der URL oder im Request. Die Seite „reflektiert“ die Eingabe sofort zurück in den HTML-Output. Typisch: ein präparierter Link, der per E-Mail oder Messenger verschickt wird. Sobald du ihn anklickst, läuft der Angriff.

Stored XSS

Das Skript wird auf der Zielseite gespeichert, etwa in einem Forenbeitrag, einem Kommentar oder einer Produktbewertung. Jeder, der die Seite später aufruft, bekommt den Schadcode automatisch geliefert. Stored XSS ist gefährlicher als die reflected-Variante, weil ein einziger Beitrag tausende Besucher infizieren kann.

DOM-based XSS

Hier kommt der Angriff ganz ohne Server-Beteiligung aus. Das Skript der Seite manipuliert das Document Object Model (DOM) deines Browsers, weil es Werte aus der URL oder dem Speicher unbedacht weiterverarbeitet. Die Lücke liegt komplett in JavaScript, das im Browser läuft.

Kurz zusammengefasst: Reflected XSS lebt im Link, Stored XSS lebt in der Datenbank der Seite, DOM-based XSS lebt im JavaScript des Browsers. Alle drei haben das gleiche Ziel: fremden Code in deinem Browser zur Ausführung bringen.

Welche Folgen kann ein XSS-Angriff haben?

Viele unterschätzen XSS, weil es im Vergleich zu klassischen Viren harmlos klingt. Tatsächlich öffnet die Lücke aber Türen für ziemlich konkrete Angriffe:

• Cookies und Sessions klauen. Der Klassiker. Wer dein Session-Cookie hat, ist im Online-Banking, im Shop oder im Postfach eingeloggt wie du. Was Cookies eigentlich sind und welche Arten es gibt, erklären wir im Beitrag Was sind Cookies im Browser?.
• Login-Daten abfischen. Das Skript blendet ein Fake-Loginfeld ein. Du tippst deine Zugangsdaten in das echte Design der Seite, die Daten landen aber beim Angreifer.
• Inhalte fälschen. Eine Newsseite kann plötzlich eine manipulierte Meldung anzeigen, die nur du zu sehen bekommst. Für Betrug oder gezielte Phishing-Mails ein gefundenes Fressen.
• Schadsoftware verteilen. Das Skript leitet dich zu Drive-by-Downloads weiter oder lädt im Hintergrund Browser-Exploits nach. Spielarten wie Rogueware und Adware werden auf diesem Weg gerne in Browser gespült.
• Browser-Profil ausspähen. Welche Plugins du nutzt, welche Webcams angeschlossen sind, welche internen URLs du im Verlauf hast: vieles davon ist per JavaScript abfragbar.

Besonders heikel: XSS läuft im Sicherheitskontext der eigentlichen Website. Was diese Seite darf, darf das Skript auch. Auf einer Banking-Seite heisst das im Zweifel: alles.

Kurz zusammengefasst: XSS reicht von „Cookie geklaut“ bis „Login-Daten abgegriffen“. Weil der Angriff auf einer legitimen Domain läuft, fallen die meisten Schutzmechanismen leise aus.

Woran erkennst du XSS als Nutzer?

Ganz ehrlich: Du erkennst gut gemachtes XSS nicht. Die Seite sieht aus wie immer. Es gibt aber Warnsignale, die dich misstrauisch machen sollten:

• Verdächtig lange URLs mit Sonderzeichen. Wenn ein Link Zeichen wie <, >, script, alert( oder %3C enthält, ist Vorsicht angebracht.
• Links aus E-Mails, Messengern oder Foren, die dich direkt auf eine Aktion lenken. Wer dir „Klick hier, dein Konto wurde gesperrt“ schickt, schickt selten harmlose URLs.
• Pop-ups, die unerwartet erscheinen. Eine echte Bank fragt nicht plötzlich per JavaScript-Dialog nach deinem Passwort.
• Seiten, die ungewöhnlich reagieren. Wenn ein Suchergebnis fehlerhaft dargestellt wird, kann das harmlos sein. Es kann aber auch ein Hinweis darauf sein, dass der Eingabewert irgendwo direkt in den Code rutscht.

Mein Tipp: Bevor du auf einen Link in einer E-Mail klickst, fahre mit der Maus darüber und schau dir die URL in der Statuszeile an. Sonderzeichen-Wirrwarr und ein langes Schwänzchen aus URL-Parametern sind Alarmzeichen. Verwandt, aber technisch anders gelagert, ist die Manipulation deiner Startseite und Suchmaschine: was du dagegen tun kannst, steht im Artikel zu Browser-Hijackern.

Kurz zusammengefasst: Du siehst XSS in der Regel nicht. Aber komische URLs, ungewollte Pop-ups und überraschende Loginfelder sind Indizien. Im Zweifel den Link nicht direkt klicken, sondern die Seite manuell aufrufen.

Wie schützen dich moderne Browser?

Die gute Nachricht zuerst: Browser haben in den letzten zwanzig Jahren massiv aufgerüstet. Vieles, was 2005 noch trivial ausnutzbar war, scheitert heute am Browser selbst.

• Same-Origin-Policy. Skripte einer Domain dürfen nicht beliebig in andere Domains hineingreifen. Klingt selbstverständlich, ist aber die Grundlage des modernen Web-Sicherheitsmodells. Eine verständliche Einführung steht in den MDN Web Docs zur Same-Origin-Policy.
• Content-Security-Policy (CSP). Eine Seite kann dem Browser sagen, von welchen Quellen Skripte überhaupt geladen werden dürfen. Inline-Skripte aus einer XSS-Lücke werden so oft schon vom Browser blockiert. Details und Beispiele liefert die CSP-Dokumentation bei MDN.
• HttpOnly-Cookies. Sessions können so gesetzt werden, dass JavaScript sie nicht lesen kann. Selbst wenn XSS gelingt, bleibt das Cookie sicher.
• Trusted Types und Sanitizer-API. Neue Browser-Funktionen, die Entwickler dabei unterstützen, Eingaben sicher in HTML zu schreiben.

Das ersetzt aber keine sichere Webseite. Wenn der Betreiber schlampt, hilft auch der beste Browser nur begrenzt. Wer einen Überblick über aktuelle Schutzthemen sucht, findet in unserer Sicherheits-Übersicht die passenden Einstiegspunkte.

Was kannst du selbst tun?

Auch wenn der Hauptschutz bei den Betreibern der Webseiten liegt, kannst du selbst eine Menge Risiko reduzieren:

1. Browser aktuell halten. Klingt langweilig, ist aber der wichtigste Hebel. Patch-Lücken in der Render-Engine sind die direkten Eintrittstüren. Welche Schutz-Tools im Browser darüber hinaus sinnvoll sind, zeigt unser Überblick zur Browsersicherheit 2026.
2. Misstrauen gegenüber Links aus unbekannter Quelle. Vor allem aus E-Mails, SMS und Messengern. Lieber selbst die Seite tippen.
3. Browser-Erweiterungen sparsam einsetzen. Eine zwielichtige Extension hat im Browser mehr Rechte als jedes XSS-Skript.
4. Wichtige Konten mit Zwei-Faktor-Authentisierung absichern. Selbst wenn ein Cookie geklaut wird, kommt der Angreifer ohne zweiten Faktor selten weit.
5. Privates und sensibles getrennt halten. Banking nicht im selben Browser-Profil wie das Forum, in dem du dich treibst.

Kurz zusammengefasst: Updates, Skepsis bei Links, Zwei-Faktor und ein sauberer Browser-Haushalt sind dein Beitrag. Den Rest erledigen Browser-Hersteller und Webseiten-Betreiber.

Ein Blick zurück: 175 XSS-Lücken auf einen Schlag

Wer früh verstehen wollte, wie verbreitet XSS wirklich ist, kam an einem Disclosure von Michael Kraus (mikx.de) im Dezember 2004 nicht vorbei. In einer einzigen Veröffentlichung machte er 175 XSS-Lücken auf einen Schlag öffentlich, quer durch alle Branchen: Microsoft, Google, Apple, Amazon, Mozilla, Heise, Bahn, Sparkasse, IBM, Adobe, NASA, eBay, PayPal, Telekom, Slashdot. Wer in dieser Liste nicht auftauchte, hatte schlicht Glück.

Der Aufschrei war beträchtlich. Der Bericht hat damals viel dazu beigetragen, XSS aus der Nischenecke der Web-Hacker in den Mainstream der IT-Sicherheit zu holen. Viele der grossen Anbieter haben ihre Eingabe-Behandlung danach ernsthaft überarbeitet, einige der damaligen Schwachstellen wurden über Jahre als Lehrbeispiele zitiert.

Heute ist das Ausmass undenkbar geworden, weil moderne Frameworks Eingaben standardmässig sicher behandeln. Aber die Geschichte zeigt: XSS ist keine theoretische Spielerei, sondern war (und ist) ein praktisches Problem auf den wichtigsten Webseiten der Welt.

Kraus hat sich nicht auf XSS beschränkt. Weitere von ihm dokumentierte Browser-Schwachstellen aus derselben Zeit sind Fire Tabbing und Fire Scrolling: zwei Lücken, die zeigen, wie selbst harmlos wirkende Browser-Funktionen zur Sicherheitsfalle werden konnten.

XSS verstehen heißt, dem Browser nicht blind zu vertrauen

Cross-Site Scripting ist alt, aber es ist nicht aus der Mode. Es lauert überall dort, wo Websites Eingaben verarbeiten, also überall. Die gute Nachricht ist, dass moderne Browser, gut gepflegte Frameworks und ein wenig Aufmerksamkeit beim Klicken den Grossteil der Risiken abfangen.

Du musst keine Sicherheitsforscherin sein, um XSS zu verstehen. Du musst nur wissen: Wenn ein Link verdächtig aussieht, sieht er meistens auch verdächtig aus, weil etwas faul ist. Lieber einmal zu vorsichtig sein als einmal zu unbedarft.

Und falls dir das Konzept jetzt vertraut vorkommt: Das ist genau der Punkt. Wer die Mechanik einmal verstanden hat, klickt im Netz aufmerksamer. Und das ist am Ende der wirksamste Schutz, den du dir selbst geben kannst.