Wie implementiert man eine Content Security Policy (CSP) mit Trusted Types, um Cross-Site Scripting (XSS) auf architektonischer Ebene zu verhindern?
Die Implementierung von Trusted Types verschiebt die XSS-Prävention von einer reaktiven Filterung hin zu einer strukturellen Typisierung. Anstatt Strings direkt an gefährliche DOM-Sinks (z. B. innerHTML, outerHTML oder document.write) zu übergeben, erzwingt der Browser die Verwendung von speziell typisierten Objekten.
Die technische Umsetzung erfolgt in drei Schritten:
- CSP-Konfiguration: Über den HTTP-Header wird die Nutzung von Trusted Types aktiviert und die erlaubten Policies definiert.
- Policy-Definition: Im Client-Code werden Richtlinien erstellt, die festlegen, wie Strings in Trusted Types umgewandelt und bereinigt werden.
- Sink-Zuweisung: Nur durch die Policy validierte Objekte werden vom Browser akzeptiert; einfache Strings lösen einen TypeError aus.
| CSP-Direktive | Funktion | Effekt |
|---|---|---|
require-trusted-types-for 'script' | Aktiviert den Modus | Blockiert alle String-Zuweisungen an gefährliche Sinks. |
trusted-types <policy-name> | Whitelist für Policies | Erlaubt nur die Nutzung spezifisch benannter Policies. |
trusted-types {allow-duplicates} | Konfigurations-Option | Steuert, ob Policies mehrfach erstellt werden dürfen. |
Die technische Umsetzung im JavaScript-Code sieht wie folgt aus:
javascript const escapeHTMLPolicy = trustedTypes.createPolicy('myEscapePolicy', { createHTML: (string) => { // Implementierung der Bereinigungslogik (z.B. via DOMPurify) return sanitize(string); } });
// Erlaubt: element.innerHTML = escapeHTMLPolicy.createHTML(userInput); // Blockiert (wirft TypeError): element.innerHTML = userInput;
Architektonisch integrieren wir diesen Ansatz in eine zentrale Security-Layer, um die Logik der Bereinigung von der Geschäftslogik zu trennen. Dies reduziert die Fehleranfälligkeit bei der manuellen Implementierung von Sanitizern in verschiedenen Modulen. In unserem IT-Consulting & Digitale Strategie begleiten wir Unternehmen bei der Migration solcher Sicherheitsarchitekturen.
Die Nutzung einer default-policy sollte vermieden werden, da sie als Fallback fungiert und die strikte Typisierung untergräbt. Wir empfehlen stattdessen die explizite Definition von benannten Policies für jeden spezifischen Anwendungsfall. Nur so wird die Angriffsfläche auf ein Minimum reduziert und die Einhaltung der Sicherheitsvorgaben über die gesamte Applikationslebenszeit hinweg garantiert.
Andere Fragen in dieser Kategorie
Andere Nutzer suchten auch nach:
Diese Fragen könnten Sie ebenfalls interessieren.
In welchen Szenarien ist die Nutzung von Conflict-free Replicated Data Types (CRDTs) gegenüber traditionellen Locking-Mechanismen vorzuziehen?
software-app-entwicklungInwiefern unterscheidet sich das State-Management-Konzept von Signal-basierten Frameworks gegenüber dem klassischen Virtual-DOM-Diffing?
software-app-entwicklungWelche Ansätze gibt es, um die Konsistenz von verteilten Caches (z. B. Redis) über mehrere Regionen hinweg zu synchronisieren?
software-app-entwicklungWelche Ansätze zur Detektion von Memory Leaks in unmanaged Code oder komplexen Heap-Strukturen sind bei High-Load-Systemen am effizientesten?
software-app-entwicklungWelche Auswirkungen hat die Nutzung von GraalVM Native Images auf die Startup-Zeit und den Memory-Footprint von Spring Boot Applikationen?