Trusted Types sind jetzt breit verfügbar – aber aktivieren Sie sie nicht blind

Eine Sicherheitsfunktion wird browserübergreifend verfügbar. Das klingt nach einem einfachen Header-Update: einschalten, deployen, fertig.

Bei Trusted Types wäre genau das riskant.

Die CSP-Direktive require-trusted-types-for 'script' kann verhindern, dass gewöhnliche Strings direkt in gefährliche DOM-Schnittstellen wie innerHTML geschrieben werden. Das verkleinert die Angriffsfläche für DOM-basiertes Cross-Site Scripting deutlich. Seit Februar 2026 führt MDN die Funktion als neu breit verfügbar in aktuellen Browsern.

Aber: Eine bestehende Website kann hunderte legitime Stellen haben, an denen Frameworks, Editoren, Analytics-Snippets oder alte Hilfsfunktionen HTML als String in den DOM schreiben. Wird die Richtlinie ohne Vorbereitung erzwungen, blockiert der Browser nicht nur Angreifer-Code, sondern auch Ihre eigenen Funktionen.

Die richtige Frage lautet deshalb nicht: „Können wir Trusted Types aktivieren?“

Sondern: „Können wir nachvollziehen, welche Teile unserer Anwendung heute unsichere DOM-Sinks verwenden, und sie kontrolliert umbauen?“

Was Trusted Types tatsächlich schützt

DOM-XSS entsteht häufig nicht durch ein unsicheres Script-Tag im HTML, sondern durch JavaScript, das nicht vertrauenswürdige Daten in eine ausführbare oder interpretierbare DOM-Schnittstelle schreibt.

Typische riskante Sinks sind beispielsweise:

• element.innerHTML
• element.outerHTML
• document.write()
• insertAdjacentHTML()
• bestimmte Script-URL- oder HTML-Zuweisungen
• Bibliotheksfunktionen, die intern dieselben Browser-APIs verwenden

Wenn Nutzereingaben, URL-Parameter, API-Daten oder CMS-Inhalte ungeprüft dort landen, kann daraus ausführbarer Markup- oder Script-Kontext entstehen.

Trusted Types verändert dieses Modell. Statt beliebige Strings zu akzeptieren, verlangen geschützte Sinks spezielle, nicht einfach fälschbare Werte wie TrustedHTML. Solche Werte dürfen nur durch benannte Policies erzeugt werden.

Das zwingt die Anwendung zu einer sichtbaren Entscheidung: Wo wird HTML erzeugt, welche Bereinigung findet statt und wer darf das tun?

Warum das kein Ersatz für eine strikte CSP ist

Trusted Types schützt eine bestimmte Klasse DOM-basierter Injection-Risiken. Es ersetzt keine Content Security Policy und keine sichere Ausgabe-Kodierung.

Eine belastbare Browser-Sicherheitsstrategie kombiniert mehrere Ebenen:

• kontextgerechte Ausgabe-Kodierung
• sichere Framework-Templates
• Vermeidung unnötiger HTML-String-APIs
• eine nonce- oder hashbasierte strikte CSP
• kontrollierte Drittanbieter-Skripte
• Trusted Types für gefährliche DOM-Sinks
• Tests und Reporting

OWASP und web.dev empfehlen für Script-Ausführung eine strikte CSP mit Nonces oder Hashes. Trusted Types ergänzt diese Ebene dort, wo JavaScript selbst DOM-Inhalte zusammensetzt.

Ein großzügiges script-src mit vielen Domains und ein Trusted-Types-Header machen unsichere Architektur nicht automatisch sicher. Beide Kontrollen müssen zu den tatsächlichen Datenflüssen passen.

Der häufigste Fehler: sofortige Erzwingung

Ein Team setzt diesen Header direkt produktiv:

Content-Security-Policy: require-trusted-types-for 'script'

Danach funktionieren plötzlich einzelne Bereiche nicht mehr:

• der Rich-Text-Editor zeigt keine Inhalte
• ein Consent-Banner öffnet sich nicht
• ein Tag-Manager-Snippet bricht
• serverseitig gelieferte HTML-Fragmente werden nicht gerendert
• eine alte Komponente zeigt nur noch leere Container
• ein Zahlungs- oder Support-Widget initialisiert nicht

Das Problem ist nicht, dass Trusted Types „zu streng“ wäre. Das Problem ist, dass die Anwendung ihre bisherigen DOM-Schreibpfade nie inventarisiert hat.

Sicherheitskontrollen sollten Fehler sichtbar machen, bevor sie geschäftskritische Funktionen blockieren.

Ein sicherer Einführungsplan

1. Zuerst die Sinks finden

Suchen Sie im eigenen Code nach direkten HTML-Zuweisungen und verwandten APIs. Berücksichtigen Sie außerdem:

• Wrapper-Funktionen
• Design-System-Komponenten
• Markdown- oder MDX-Renderer
• CMS-Vorschauen
• Rich-Text-Editoren
• alte jQuery- oder Plugin-Aufrufe
• Drittanbieter-SDKs
• Tag-Manager und Consent Manager

Eine Textsuche ist nur der Anfang. Viele Bibliotheken kapseln die gefährliche API intern.

2. Report-Only statt Blockieren

Führen Sie Trusted Types zunächst über Content-Security-Policy-Report-Only ein. So kann der Browser Verstöße melden, ohne die Funktion sofort zu stoppen.

Der Reporting-Endpunkt muss dabei wirklich funktionieren. Ein Header ohne empfangene, gruppierte und ausgewertete Reports ist nur Dekoration.

Erfassen Sie mindestens:

• betroffene URL
• konkrete Direktive
• Script- oder Komponenten-Kontext
• Release-Version
• Häufigkeit
• Browser
• Nutzerweg

Achten Sie auf Datenschutz und Datenminimierung. Report-URLs und Script-Informationen können interne Pfade oder Parameter enthalten.

3. Unsichere Muster entfernen, nicht nur umhüllen

Die beste Korrektur ist oft, gar kein HTML als String zu erzeugen.

Bevor Sie eine Trusted-Type-Policy schreiben, prüfen Sie:

• Kann textContent statt innerHTML verwendet werden?
• Kann das Framework JSX, Templates oder sichere DOM-Methoden nutzen?
• Kann die Komponente strukturierte Daten statt HTML erhalten?
• Kann ein Drittanbieter-Widget isoliert oder ersetzt werden?
• Muss dieser dynamische HTML-Pfad überhaupt existieren?

Eine Policy, die jeden String ungeprüft als TrustedHTML zurückgibt, erfüllt formal die Schnittstelle und zerstört praktisch den Sicherheitsgewinn.

4. Policies klein und benannt halten

MDN beschreibt mit der Direktive trusted-types, welche Policy-Namen erstellt werden dürfen. Das macht unkontrollierte Policy-Erzeugung sichtbar.

Statt einer globalen Policy wie default für die gesamte Anwendung sind eng begrenzte Policies leichter zu prüfen, zum Beispiel:

• sanitized-markdown
• cms-preview
• legacy-editor-adapter

Jede Policy sollte einen klaren Zweck, einen Eigentümer und eine konkrete Bereinigungsstrategie haben.

5. Sanitizer bewusst konfigurieren

Wenn HTML wirklich erforderlich ist, braucht es eine etablierte, passend konfigurierte Sanitization-Lösung. Prüfen Sie insbesondere:

• erlaubte Elemente und Attribute
• URL-Schemata
• SVG- und MathML-Verhalten
• eingebettete Medien
• Event-Handler
• Style-Attribute
• Links mit target
• benutzerdefinierte Elemente

„Wir verwenden einen Sanitizer“ ist erst dann eine belastbare Aussage, wenn seine Konfiguration und sein Einsatzort geprüft wurden.

6. Drittanbieter separat bewerten

Ein großes Hindernis sind häufig nicht die eigenen Komponenten, sondern eingebettete Dienste. Fragen Sie für jedes Widget:

• Unterstützt der Anbieter Trusted Types?
• Welche Sinks verwendet das SDK?
• Kann es in einem iframe isoliert werden?
• Gibt es eine aktuellere Integrationsvariante?
• Ist das Widget geschäftskritisch?
• Was passiert, wenn es blockiert wird?

Eine Sicherheitskontrolle sollte nicht stillschweigend durch eine universelle Ausnahme für sämtliche Drittanbieter ausgehebelt werden.

7. Kritische Nutzerwege testen

Vor der Erzwingung brauchen Sie echte End-to-End-Tests für:

• Login und Registrierung
• Kontakt- und Bewerbungsformulare
• Checkout und Zahlung
• Cookie- und Consent-Flows
• Rich-Text- oder CMS-Inhalte
• Support-, Chat- und Terminwidgets
• eingeloggte Dashboards
• Datei- und Medienvorschauen

Testen Sie nicht nur, ob die Seite lädt. Prüfen Sie die fachliche Aktion bis zum Erfolgssignal.

Sechs Red Flags in bestehenden Implementierungen

1. Eine Default-Policy vertraut jedem String.
   Die Anwendung funktioniert wieder, aber der Schutz ist faktisch aufgehoben.

2. Report-Only läuft seit Monaten ohne Auswertung.
   Daten werden gesammelt, aber keine Komponente wird verbessert.

3. Nur eigener Code wurde geprüft.
   Tag Manager, Consent Manager und Widgets bleiben blinde Flecken.

4. Die Richtlinie wird nur auf der Startseite gesetzt.
   App, Checkout, Adminbereich oder Sprachversionen liefern andere Header.

5. CSP wird von mehreren Ebenen erzeugt.
   Anwendung, CDN und Reverse Proxy senden widersprüchliche oder doppelte Direktiven.

6. Ein Release wird nur mit Entwicklerprofilen getestet.
   Gespeicherte Einwilligungen, Extensions und Admin-Sessions verdecken reale Nutzerfehler.

Was Website-Pflichtencheck prüfen würde

Ein technischer Trusted-Types- und CSP-Check betrachtet nicht nur, ob ein Header existiert. Er kann untersuchen:

• tatsächlich ausgelieferte CSP-Header auf unterschiedlichen Seitentypen
• DOM-Sinks im eigenen und eingebundenen Code
• Report-Only-Konfiguration und Report-Pipeline
• Policy-Namen, Scope und Sanitizer
• Framework-, CMS- und Editor-Integrationen
• Drittanbieter-Widgets und Tag-Manager
• Abweichungen zwischen Produktion, Preview und Staging
• kritische Nutzerwege unter erzwungener Richtlinie
• Regressionstests und Release-Monitoring
• Wechselwirkungen mit Nonces, Hashes und strict-dynamic

Das Ziel ist nicht, einen modernen Sicherheitsheader möglichst schnell zu aktivieren. Das Ziel ist, die Stellen sichtbar zu machen, an denen die Anwendung HTML vertraut, und dieses Vertrauen auf wenige überprüfbare Pfade zu begrenzen.

Trusted Types ist deshalb mehr als eine Browserfunktion. Es ist ein Architekturtest.

Wenn Ihre Anwendung nur funktioniert, solange jeder String als vertrauenswürdig gelten darf, ist nicht die Sicherheitsrichtlinie das Problem. Sie hat lediglich sichtbar gemacht, wo Kontrolle bisher gefehlt hat.