Teil 3 der Serie „EU Web Security: In 10 Schritten zum besseren Rating"
Warum CSP wichtig ist
Cross-Site Scripting (XSS) ist seit über 20 Jahren die häufigste Schwachstelle in Web-Anwendungen. Ein Angreifer schleust JavaScript-Code in Ihre Website ein — über ein Formular, einen URL-Parameter, einen Kommentar. Der Browser des Besuchers führt den Code aus, weil er nicht weiß, dass er nicht zur Seite gehört.
Content Security Policy (CSP) löst dieses Problem: Sie definieren explizit, welche Quellen der Browser für Skripte, Styles, Bilder und andere Ressourcen akzeptieren darf. Alles andere wird blockiert.
Adoptionsrate in der EU: 10,8%. Neun von zehn Websites haben keinen CSP-Header.
Was die Daten zeigen
Aus dem SiteGuardian Benchmark mit über 700.000 europäischen Websites:
- 10,8% haben einen CSP-Header
- Websites mit security.txt haben CSP in 47% der Fälle — 4,7× häufiger
- Permissions-Policy (verwandter Header): nur 6,4%
CSP schrittweise einführen
Das größte Hindernis: eine zu strenge CSP bricht die Seite. Google Analytics lädt nicht, eingebettete YouTube-Videos verschwinden, Inline-Styles funktionieren nicht mehr.
Schritt 1: Report-Only Modus (bricht nichts)
Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report
Der Browser meldet Verstöße, blockiert aber nichts. Sie sehen, welche externen Quellen Ihre Seite nutzt, ohne etwas kaputtzumachen.
Schritt 2: Quellen identifizieren
Beobachten Sie die Reports 1-2 Wochen. Typische Quellen die Sie freigeben müssen:
- Google Analytics:
https://www.googletagmanager.com https://www.google-analytics.com - Google Fonts:
https://fonts.googleapis.com https://fonts.gstatic.com - YouTube Embeds:
https://www.youtube.com https://www.youtube-nocookie.com - Ihr CDN:
https://cdn.ihre-domain.de
Schritt 3: Policy bauen
Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src https://fonts.gstatic.com; img-src 'self' data: https:; frame-src https://www.youtube-nocookie.com
Schritt 4: Aktivieren
Entfernen Sie -Report-Only aus dem Header-Namen. Testen Sie die Seite gründlich.
Die wichtigsten Direktiven
| Direktive | Kontrolliert | Empfehlung |
|---|---|---|
default-src |
Fallback für alles | 'self' |
script-src |
JavaScript | 'self' + explizite Domains |
style-src |
CSS | 'self' 'unsafe-inline' (oft nötig) |
img-src |
Bilder | 'self' data: https: |
font-src |
Schriften | 'self' + Google Fonts wenn nötig |
connect-src |
XHR/Fetch | 'self' + API-Domains |
frame-src |
iframes | Nur explizite Domains |
object-src |
Flash/Java | 'none' (immer) |
base-uri |
base-Tag | 'self' |
Nginx
add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; object-src 'none'; base-uri 'self'" always;
Apache
Header always set Content-Security-Policy "default-src 'self'; script-src 'self' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; object-src 'none'; base-uri 'self'"
Häufige Fehler
1. unsafe-inline für Skripte. script-src 'unsafe-inline' erlaubt jedes Inline-Script — das macht die gesamte CSP wertlos gegen XSS. Nutzen Sie stattdessen Nonces oder Hashes.
2. * als Quelle. default-src * erlaubt alles von überall. Das ist keine Policy, das ist ein Placebo.
3. Zu streng starten. Beginnen Sie immer mit Report-Only. Eine CSP die die Seite bricht und sofort deaktiviert wird, schützt niemanden.
Regulatorischer Kontext
- NIS2 Art. 21(2)(d) — Sicherheit bei Entwicklung und Wartung von Informationssystemen
- DSGVO Art. 32 — XSS kann zu Datenschutzverletzungen führen (Session-Hijacking, Cookie-Diebstahl)
- PCI DSS 4.0 — Requirement 6.4.3 verlangt explizit CSP für Payment Pages
Prüfen Sie Ihre CSP
SiteGuardian zeigt Ihnen nicht nur ob ein CSP-Header existiert, sondern analysiert die Direktiven auf bekannte Schwächen:
Nächste Woche in Teil 4: DNSSEC — warum 84% der EU-Domains keinen Schutz vor DNS-Manipulation haben.