1. Was ist die Content Security Policy (CSP)?
Die Content Security Policy (CSP) ist ein vom W3C standardisierter HTTP-Header, mit dem Webseiten deklarieren, welche Ressourcen der Browser laden und ausführen darf.
Indem sie Quellen für Skripte, Stylesheets und Netzwerkanfragen einschränkt, ist die CSP die stärkste Verteidigungslinie gegen Cross-Site Scripting (XSS).
2. Die wichtigsten Direktiven im Überblick
| DIREKTIVE | KONTROLLIERT | SICHERE EMPFEHLUNG |
|---|---|---|
| default-src | Fallback für alle nicht deklarierten Fetch-Direktiven | 'self' |
| script-src | Zulässige Ausführungsquellen für JavaScript | 'self' 'nonce-...' |
| style-src | Zulässige Quellen für CSS und Inline-Styles | 'self' 'unsafe-inline' |
| connect-src | Erlaubte Ziele für Fetch, XHR und WebSockets | 'self' https://api.domain.com |
| frame-ancestors | Domains, die diese Seite in <iframe> einbetten dürfen | 'none' |
3. Nonce- vs. Hash-basierte Richtlinien
Frühere CSP-Versionen verließen sich auf Domain-Whitelists, die jedoch anfällig für Umgehungen auf CDNs waren. Moderne Standards setzen auf kryptografische Nonces.
Strikte CSP (Level 3) löst dies durch einmalige Nonces pro Anfrage:
Content-Security-Policy: script-src 'nonce-rAnd0m123' 'strict-dynamic'; object-src 'none';
4. Frame Ancestors vs. X-Frame-Options
Während X-Frame-Options: DENY noch aus Kompatibilitätsgründen existiert, bietet die CSP-Direktive frame-ancestors flexiblere Kontrolle gegen Clickjacking.
5. Rollout-Plan in 3 Schritten
Phase 1: Nur-Bericht-Modus (Report-Only): Starten Sie mit <code>Content-Security-Policy-Report-Only</code>, um Sicherheitsverletzungen ohne Ausfälle zu protokollieren.
Phase 2: Bereinigung von Inline-Code: Überführen Sie <code>onclick="..."</code>-Attribute in externe JavaScript-Event-Listener.
Phase 3: Strikte Durchsetzung: Aktivieren Sie <code>Content-Security-Policy</code> mit <code>object-src 'none'</code> zur vollständigen Absicherung.