Ihre CSP stoppt kein DOM-XSS. Trusted Types schon.

Eine gut gebaute Content-Security-Policy beantwortet eine Frage: Woher darf diese Seite Skripte laden?

DOM-XSS lädt kein Skript. Es nimmt eine Zeichenkette, der die Anwendung bereits vertraut, und übergibt sie einer Browser-API, die Zeichenketten in Code verwandelt. innerHTML. document.write. eval. Das Skript überquert nie das Netz, es gibt also keine Herkunft, die die CSP erlauben oder verweigern könnte.

Deshalb liefern Teams mit nonce-basierter CSP und einem sauberen Security-Header-Bericht weiterhin DOM-XSS aus.

Was Trusted Types ändert

Trusted Types dreht das Problem um. Statt gefährliche Zeichenketten erkennen zu wollen, hindert es die gefährlichen APIs daran, überhaupt Zeichenketten anzunehmen.

Mit erzwungenen Trusted Types wirft element.innerHTML = benutzerEingabe eine Ausnahme. Der einzige Weg, in diese Senke zu schreiben, führt über ein TrustedHTML-Objekt, und der einzige Weg, ein solches zu erhalten, führt über eine Richtlinie, die Sie ausdrücklich deklariert haben:

const policy = trustedTypes.createPolicy('sanitizer', {
  createHTML: (input) => DOMPurify.sanitize(input),
});

element.innerHTML = policy.createHTML(benutzerEingabe);

Die Sicherheitseigenschaft ist strukturell, nicht verhaltensbasiert. Jeder Pfad zu einer DOM-Injektionssenke führt nun durch Code, den Sie benannt haben. Damit wandelt sich die Auditfrage von “sind alle vierhundert Zuweisungen sicher?” zu “sind diese drei Richtlinien korrekt?”.

Das ist eine Frage, die ein Mensch tatsächlich beantworten kann.

Die beiden Direktiven

Content-Security-Policy:
  require-trusted-types-for 'script';
  trusted-types sanitizer default;

require-trusted-types-for 'script' aktiviert die Durchsetzung an den Senken.

trusted-types deklariert die Positivliste der Richtliniennamen. Sie wird leicht weggelassen und lohnt sich. Ohne sie kann beliebiger Code auf der Seite, auch ein kompromittiertes Drittanbieter-Skript, createPolicy() mit beliebigem Namen aufrufen und vertrauenswürdige Werte erzeugen. Mit ihr wirft createPolicy() bei einem nicht gelisteten Namen eine Ausnahme, sodass die Menge der Codepfade, die vertrauenswürdige Werte erzeugen können, festgelegt und prüfbar ist.

Eine CSP mit require-trusted-types-for ohne trusted-types hat die Durchsetzung und verliert die Nachvollziehbarkeit. Das ist ein echtes, aber unvollständiges Deployment.

Browserunterstützung

Trusted Types funktioniert seit Februar 2026 über die aktuellen Browserversionen hinweg. Ältere Versionen ignorieren die Direktiven vollständig, wodurch das Deployment risikolos ist: Nicht unterstützende Browser verhalten sich exakt wie heute, unterstützende erhalten den Schutz.

Ein Kompatibilitätsargument fürs Abwarten gibt es nicht.

Ausrollen, ohne die Anwendung zu brechen

Die Durchsetzung ist strikt, und eine gewachsene Codebasis wird Verstöße aufweisen. Fahren Sie zuerst im Report-only-Modus.

1. Liefern Sie Content-Security-Policy-Report-Only mit beiden Direktiven und einem report-to-Endpunkt aus.
2. Sammeln Sie Verstöße. Jeder ist eine echte Zuweisung an eine DOM-Senke, und der Bericht nennt Datei und Zeile.
3. Leiten Sie jede über eine Richtlinie, oder entfernen Sie die Zuweisung.
4. Ergänzen Sie bei großem Volumen eine default-Richtlinie als vorübergehende Zwischenschicht. Sie fängt alles noch nicht Migrierte ab, was früheres Erzwingen erlaubt und die Zwischenschicht über die Zeit schrumpfen lässt.
5. Stellen Sie den Header auf Durchsetzung um.

Der Berichtsschritt zahlt sich schon vor der Durchsetzung aus, denn die Verstoßliste ist ein Inventar der DOM-Senken, das keine statische Analyse ebenso genau erzeugt.

Zusammenspiel mit der übrigen Policy

Trusted Types ist eine Schicht. Die übrigen Bestandteile einer modernen CSP:

Direktive	Verhindert
script-src mit Nonce und strict-dynamic	Eingeschleuste externe Skripte
object-src 'none'	Ausführung über Plugins
base-uri 'self'	<base>-Injektion, die relative URLs entführt
frame-ancestors 'none'	Clickjacking, genauer als X-Frame-Options
require-trusted-types-for 'script'	DOM-XSS an der Senke

Positivlisten in script-src gelten inzwischen als überholt: Sie werden unpflegbar und sind regelmäßig über die erlaubten Herkünfte selbst umgehbar. Nonce plus strict-dynamic ist die aktuelle Empfehlung.

Wichtig zu wissen, was CSP überhaupt nicht abdeckt: serverseitige Schwachstellen und eine Lieferkettenkompromittierung einer Skriptquelle, der Sie bereits vertrauen. Für Letzteres brauchen Sie Subresource Integrity und den zugehörigen Durchsetzungs-Header.

Zuordnung zu Rahmenwerken

• NIS2 Artikel 21(2)(g), Cyberhygiene, und 21(2)(e), Netz- und Systemsicherheit.
• ISO/IEC 27001:2022 A.8.28 (sichere Entwicklung) und A.8.26 (Anforderungen an Anwendungssicherheit).
• OWASP Top 10 A03:2021, Injection.

Prüfung

curl -sI https://ihredomain.de | grep -i content-security-policy

Achten Sie auf beide Direktiven. Ein SaaSFort-Scan meldet drei getrennte Zustände, weil es tatsächlich unterschiedliche Haltungen sind: beide Direktiven vorhanden, Durchsetzung ohne Positivliste, und keine von beiden.

Kurzfassung

CSP steuert Skript-Quellen. Trusted Types steuert Skript-Senken. Beide adressieren verschiedene Hälften derselben Angriffsklasse, und die meisten SaaS-Anwendungen haben 2026 nur die erste Hälfte ausgerollt.

Report-only kostet nichts und liefert ein Inventar sämtlicher DOM-Senken Ihrer Anwendung. Fangen Sie dort an.