Wie kann die Content Security Policy (CSP) konfiguriert werden, um XSS-Angriffe effektiv zu verhindern, ohne die Funktionalität von Third-Party-Skripten vollständig zu blockieren?

Die effektive Konfiguration einer Content Security Policy (CSP) zur XSS-Prävention basiert auf dem Prinzip des Least Privilege. Wir setzen hierbei auf eine sogenannte „Strict CSP“, die den Fokus von einer fehleranfälligen Domain-Whitelist hin zu einer kryptografischen Validierung verschiebt.

Anstatt einzelne URLs von Third-Party-Anbietern zu listen – was oft Sicherheitslücken öffnet, da CDNs häufig auch benutzergenerierte Inhalte hosten –, nutzen wir Nonces (Number used once). Ein Nonce ist ein einmaliger, kryptografisch sicherer Zufallswert, der bei jedem Request neu generiert und im HTTP-Header sowie im <script>-Tag hinterlegt wird.

Die folgende Tabelle zeigt die empfohlene Konfiguration für eine moderne, sichere CSP:

Durch die Kombination von nonce- und strict-dynamic wird die Funktionalität von Third-Party-Skripten gewahrt: Sobald ein Hauptskript durch den Nonce autorisiert wurde, darf dieses Skript weitere Abhängigkeiten laden, ohne dass jede einzelne URL in der Policy definiert sein muss. Die Einträge https: und 'unsafe-inline' dienen lediglich als Fallback für ältere Browser, die strict-dynamic nicht unterstützen.

Die Implementierung dieser Architektur ist ein zentraler Bestandteil unserer IT-Consulting & Digitale Strategie, um Webanwendungen gegen moderne Injection-Vektoren abzusichern. Zur Überwachung nutzen wir den report-uri oder report-to Endpunkt, um Blockaden in Echtzeit zu analysieren, ohne die User Experience zu beeinträchtigen.

Wir empfehlen den vollständigen Verzicht auf Domain-Whitelists in der script-src. Whitelists suggerieren Sicherheit, sind aber in der Praxis aufgrund von JSONP-Endpunkten oder offenen Redirects auf Drittanbieter-Plattformen oft wirkungslos. Die einzige technisch belastbare Lösung für skalierbare Enterprise-Anwendungen ist die konsequente Nutzung von Nonces in Verbindung mit strict-dynamic.