Glossar, ISMS / Sichere Softwareentwicklung / Schwachstellenklasse

DOM XSS

Englisch: DOM-based Cross-Site Scripting (DOM XSS, Type 0 XSS)

Zuletzt aktualisiert: Mai 2026

Lesedauer: ca. 5 Minuten

DOM XSS ist eine Schwachstellenklasse clientseitiger Webanwendungen, bei der Schadcode nicht durch den Server, sondern im Browser des Nutzers zur Laufzeit in das Document Object Model (DOM) injiziert wird. MITRE klassifiziert DOM XSS als Subtyp von CWE-79 (Improper Neutralization of Input During Web Page Generation) und unterscheidet ihn von Reflected XSS (Typ 1) und Stored XSS (Typ 2) dadurch, dass der Angriffspfad vollständig clientseitig verläuft.

Normative Grundlage: MITRE CWE-79 (Improper Neutralization of Input During Web Page Generation), DOM-based XSS als Subtyp; ISO/IEC 27001:2022 Annex A 8.28 (Secure Coding)

Hintergrund und normative Einordnung

Der Begriff DOM XSS wurde in der Sicherheitsforschung bereits 2005 durch Amit Klein formalisiert, bevor MITRE ihn als Subtyp in CWE-79 aufnahm. Die CWE-Klassifikation beschreibt alle XSS-Varianten als Manifestationen desselben Grundproblems: unzureichende Neutralisierung von Nutzereingaben vor ihrer Verwendung in webseiten-generierenden Ausgabepfaden. Was DOM XSS von seinen serverseitigen Varianten trennt, ist der Ausführungskontext: Die Injektion geschieht im Browser, nachdem die Seite den Server bereits verlassen hat. Typische Source-Vektoren sind URL-Fragmente (location.hash, location.search), postMessage-Events, document.referrer oder localStorage-Einträge. Typische Sink-Vektoren sind JavaScript-Funktionen, die unkontrollierte Strings direkt in den DOM schreiben, allen voran innerHTML, outerHTML, document.write und eval().

In der deutschen Compliance-Landschaft ist DOM XSS primär über zwei Regelwerke adressiert. ISO/IEC 27001:2022 Annex A 8.28 fordert Organisationen auf, Prinzipien sicherer Softwareentwicklung anzuwenden, einschließlich Input-Validierung, Output-Encoding und sicherer Verwendung von APIs, alle drei Prinzipien schließen DOM-XSS-Vektoren direkt ein. Der BSI IT-Grundschutz Baustein APP.3.1 (Webanwendungen und Webservices, Edition 2023) verlangt in der Standardanforderung APP.3.1.A3 explizit die Absicherung von Webanwendungen gegen Injection-Angriffe einschließlich Cross-Site-Scripting durch kontextabhängiges Encoding. Der BSI-Baustein CON.10 (Entwicklung von Webanwendungen) ergänzt diese Betreiberperspektive um Entwicklungsrichtlinien zur Verhinderung clientseitiger Injektionen. Mit dem EU Cyber Resilience Act (Verordnung (EU) 2024/2847) rückt DOM XSS auch für Produkthersteller in den Pflichtrahmen: Annex I Part I verlangt, dass Produkte mit digitalen Elementen ohne bekannte ausnutzbare Schwachstellen ausgeliefert werden; Part II verpflichtet Hersteller zu einem dokumentierten Schwachstellen-Handling-Prozess. Für Unternehmen, die hier Unterstützung benötigen, bietet SECURAM CRA-Beratung (Cyber Resilience Act) einen strukturierten Einstieg in die CRA-Konformität.

Normative Bezüge:

MITRE CWE-79, DOM-based XSS (Type 0) ISO/IEC 27001:2022 Annex A 8.28 (Secure Coding) Verordnung (EU) 2024/2847 (CRA) Annex I

Vorgehen in der Praxis

Die systematische Adressierung von DOM XSS folgt in der Praxis einem vierstufigen Ablauf, der sich aus den Anforderungen von ISO/IEC 27001:2022 Annex A 8.28, BSI IT-Grundschutz APP.3.1 und den Vulnerability-Handling-Vorgaben des CRA Annex I Part II ableiten lässt. Der Ablauf deckt Erkennung, Prüfung, Behebung und Nachweise für Auditoren ab.

DOM-Datenflüsse kartieren (Threat Modeling) Alle clientseitigen Source-Vektoren (URL-Parameter, Fragmente, postMessage, localStorage, document.referrer) und Sink-Vektoren (innerHTML, outerHTML, document.write, eval, setTimeout mit String-Argument) im JavaScript-Code werden vollständig erfasst. NIST SP 800-115 empfiehlt die Kombination aus Code Review und dynamischem Testen als Basis für die Identifikation von Injection-Pfaden in Webanwendungen. BSI APP.3.1 und CON.10 fordern eine dokumentierte Architekturübersicht als Voraussetzung für die risikobasierte Absicherung.

SAST und DAST-gestützte Prüfung Statische Analyse (SAST) prüft den Quellcode auf unsichere DOM-Manipulation, dynamische Analyse (DAST) simuliert Angriffe mit präparierten URL-Fragmenten und Event-Payloads gegen die laufende Anwendung. ISO/IEC 27001:2022 Annex A 8.28 verlangt die Integration von Sicherheitstests in den Entwicklungsprozess. Der CRA Annex I Part II §3 verpflichtet Produkthersteller darüber hinaus zu regelmäßigen Sicherheitstests und -überprüfungen über den gesamten Produktlebenszyklus.

Sichere Codierung und Sanitization implementieren Behebung erfolgt durch drei aufeinander aufbauende Kontrollen: (1) Kontextbezogenes Output-Encoding (HTML-, JavaScript- und URL-Kontext separat behandeln) für alle DOM-Schreiboperationen, (2) Sanitization durch eine dedizierte Bibliothek wie DOMPurify vor dem Einfügen von HTML-Inhalten, (3) Deployment einer strikten Content Security Policy (CSP), die inline Script-Ausführung einschränkt. Das W3C Trusted Types API kann zusätzlich durchsetzen, dass DOM-Sinks ausschließlich vorgeprüfte Objekte akzeptieren. ISO/IEC 27002:2022 Clause 8.28 nennt explizit Input-Validierung und sichere API-Nutzung als Kernanforderungen.

Nachweis und Disclosure dokumentieren Behobene Schwachstellen werden mit CVE-Referenz oder internem Ticket, Testnachweis (DAST-Report vor/nach Patch), Patchdatum und Versionsnummer dokumentiert. Für Produkthersteller unter dem CRA ist die öffentliche Offenlegung behobener Schwachstellen gemäß Annex I Part II §4 verpflichtend. ISO/IEC 27001:2022 Annex A 8.8 (Management of technical vulnerabilities) verlangt zudem einen dokumentierten Prozess für zeitnahe Behebung und Nachweis der Wirksamkeit.

Die effektivste Einzelmaßnahme gegen DOM XSS ist die konsequente Trennung von Daten und Code im DOM: Wer statt innerHTML ausschließlich textContent oder createElement für dynamische Inhalte verwendet, eliminiert den primären Sink-Vektor, ohne CSP oder Sanitization-Bibliotheken zu benötigen, dieses Prinzip entspricht dem in ISO/IEC 27002:2022 Clause 8.28 geforderten Grundsatz der sicheren API-Nutzung.

Abgrenzung zu verwandten Begriffen

Begriff	Fokus	Verhältnis zu DOM XSS
Reflected XSS	Serverseitige Reflexion von Eingaben in der HTTP-Antwort	Reflected XSS (CWE-79 Typ 1) entsteht, wenn ein Server Nutzereingaben aus dem HTTP-Request ungefiltert in die HTTP-Antwort einbettet. Im Gegensatz zu DOM XSS passiert der Schadcode den Server und kann dort durch serverseitige Eingabefilterung abgefangen werden. DOM XSS umgeht diesen Schutz vollständig, da die Injektion erst nach der Serverantwort im Browser stattfindet.
Stored XSS	Persistente Speicherung von Schadcode in der Datenbank	Stored XSS (CWE-79 Typ 2) schreibt den Angriffscode dauerhaft in einen Datenspeicher (Datenbank, Log, Kommentarfeld) und infiziert jeden Seitenaufruf. DOM XSS hingegen ist meist flüchtig und an einen spezifischen, präparierten Link gebunden. Beide Typen können sich überlagern, wenn eine Webanwendung gespeicherte Daten ohne Encoding per JavaScript in den DOM schreibt.
Cross-Site Request Forgery (CSRF)	Erzwingen authentifizierter Aktionen im Namen des Opfers	CSRF (CWE-352) missbraucht die Sitzungsauthentifizierung eines eingeloggten Nutzers, um serverseitige Aktionen auszuführen, ohne Schadcode im Browser des Opfers auszuführen. DOM XSS führt dagegen beliebigen JavaScript-Code im Kontext der Zieldomain aus und kann dadurch CSRF-Token auslesen oder CSRF-Angriffe automatisieren. Beide Schwachstellen sind verwandt, aber strukturell unterschiedliche Klassen.

Typische Fehler und wie ihr sie vermeidet

Serverseitige Filterung als ausreichend betrachten: Der häufigste Irrtum bei DOM XSS ist die Annahme, ein serverseitiger WAF- oder Input-Filter schütze vor allen XSS-Varianten. Da der DOM-XSS-Angriffsvektor vollständig im Browser abläuft, oft über location.hash, das nie zum Server gesendet wird, greifen serverseitige Kontrollen nicht. MITRE CWE-79 weist explizit darauf hin, dass die Filterung allein in einem der beteiligten Layer (Server oder Client) keine ausreichende Mitigation darstellt.
innerHTML ohne Sanitization für dynamische Inhalte verwenden: Entwickler nutzen innerHTML aus Bequemlichkeit für dynamisches Rendering. Jede Zuweisung von nicht sanitisierten Strings an innerHTML ist ein potenzieller DOM-XSS-Sink. ISO/IEC 27002:2022 Clause 8.28 fordert die sichere Nutzung von APIs; innerHTML mit nicht vertrauenswürdigen Daten entspricht explizit nicht diesem Standard. BSI CON.10 verlangt, dass Ausgabe-Encoding und Sink-Kontrollen in Entwicklungsrichtlinien festgelegt werden.
Content Security Policy nur als Audit-Nachweis ohne Wirkung deployen: Viele Organisationen setzen eine CSP-Header um, lassen jedoch unsafe-inline und unsafe-eval zu, um Kompatibilitätsprobleme zu vermeiden. Eine CSP mit diesen Direktiven bietet keinen wirksamen Schutz gegen DOM XSS. Eine wirksame CSP erfordert die vollständige Eliminierung von inline Scripts und den Einsatz von Nonces oder Hashes, eine Anforderung, die in BSI APP.3.1 und ISO/IEC 27002:2022 Clause 8.28 durch den Verweis auf bewährte Sicherheitspraktiken impliziert ist.
Fehlende Abdeckung von DOM-XSS-Sinks im DAST: Standard-DAST-Scans testen häufig nur Reflected und Stored XSS-Varianten über HTTP-Request/Response-Zyklen. DOM-XSS-Sinks, die über URL-Fragmente, postMessage oder Event-Handler erreichbar sind, bleiben ohne speziell konfigurierte, browserbasierte Testumgebungen unentdeckt. NIST SP 800-115 betont, dass Web Application Testing die Kombination aus automatisierten Scans und manuellen Prüftechniken erfordert, um alle Angriffsvektoren abzudecken.

Relevanz im regulatorischen Kontext

Die Verordnung (EU) 2024/2847 (Cyber Resilience Act) schafft ab dem 11. Dezember 2027 einen verbindlichen Pflichtrahmen für Hersteller von Produkten mit digitalen Elementen. Annex I Part I verlangt, dass solche Produkte ohne bekannte ausnutzbare Schwachstellen auf den Markt gebracht werden, DOM XSS-Schwachstellen, die zum Zeitpunkt des Inverkehrbringens bekannt sind, erfüllen diesen Anspruch nicht. Annex I Part II §1 verpflichtet Hersteller zusätzlich, Schwachstellen einschließlich ihrer Komponenten zu dokumentieren und unverzüglich zu beheben; §3 fordert regelmäßige Sicherheitstests; §5 verlangt die Implementierung koordinierter Schwachstellen-Offenlegungs-Prozesse.

Auf Normenebene bindet ISO/IEC 27001:2022 Annex A 8.28 alle zertifizierten Organisationen, die Software entwickeln oder entwickeln lassen, an Prinzipien sicherer Codierung, einschließlich Eingabevalidierung, Output-Encoding und sicherer DOM-Manipulation. ISO/IEC 27002:2022 Clause 8.28 konkretisiert dies durch Verweis auf branchenanerkannte Benchmarks wie OWASP Top 10 und CWE-Listen als normativen Maßstab. Für Bundesbehörden und KRITIS-Betreiber verankert BSI IT-Grundschutz APP.3.1 (Edition 2023) den Schutz vor Cross-Site-Scripting als Standardanforderung für den Betrieb von Webanwendungen. NIS-2 (Richtlinie (EU) 2022/2555, Artikel 21) fordert von wesentlichen und wichtigen Einrichtungen risikobasierte technische Sicherheitsmaßnahmen, unter die eine ungesicherte Webanwendung mit bekannten XSS-Schwachstellen fällt.

Häufige Fragen

Was unterscheidet DOM XSS grundsätzlich von Reflected XSS?

Bei Reflected XSS verarbeitet der Server die Angreifer-Eingabe und gibt sie in der HTTP-Antwort zurück, der Schadcode passiert den Server und kann dort gefiltert werden. Bei DOM XSS verbleibt der Angriffspfad vollständig im Browser: JavaScript-Code der Seite liest unkontrollierte Quellen (z. B. location.hash) und schreibt deren Inhalt direkt in den DOM. Serverseitige Filter greifen nicht, da der HTTP-Server die manipulierte Eingabe nie zu sehen bekommt. MITRE klassifiziert DOM XSS deshalb als eigenständigen Subtyp (Type 0) innerhalb von CWE-79.

Reicht eine Web Application Firewall (WAF) als Schutz gegen DOM XSS aus?

Nein. Eine WAF analysiert den HTTP-Datenverkehr zwischen Client und Server. DOM-XSS-Angriffe, die ausschließlich über das URL-Fragment (der Teil nach dem #-Zeichen) oder clientseitige Ereignisse wie postMessage eingeleitet werden, generieren keinen abfangbaren HTTP-Request mit dem Schadpayload. Der wirksame Schutz erfordert sichere Codierung auf Ebene der JavaScript-Logik (Output-Encoding, DOMPurify, Trusted Types) sowie eine restriktive Content Security Policy, Maßnahmen, die ISO/IEC 27002:2022 Clause 8.28 im Rahmen sicherer Programmierprinzipien fordert.

Welche Pflichten entstehen für Unternehmen aus dem Cyber Resilience Act konkret bei DOM XSS?

Für Hersteller von Produkten mit digitalen Elementen verlangt CRA Annex I Part I, dass bekannte ausnutzbare Schwachstellen, einschließlich DOM XSS, vor dem Inverkehrbringen behoben sind. Part II §1 verpflichtet zu einem dokumentierten Schwachstellen-Handling-Prozess mit Behebungsfristen, Part II §3 zu regelmäßigen Sicherheitstests (SAST/DAST). Organisationen, die ISO/IEC 27001:2022 betreiben, müssen zusätzlich gemäß Annex A 8.28 nachweisen, dass ihre Entwicklungsprozesse sichere Programmierprinzipien zur Vermeidung von DOM-XSS-Vektoren systematisch umsetzen.