Content Security Policy (CSP): Der wichtigste Schutz gegen XSS
CSP ist die wirksamste Verteidigung gegen Cross-Site Scripting. Erfahren Sie, wie der Header funktioniert, welche Direktiven Sie brauchen und wie Sie CSP in 3 Schritten implementieren.
Warum Content Security Policy?
Content Security Policy (CSP) ist ein HTTP-Header, der dem Browser eine Whitelist erlaubter Ressourcen mitteilt und alles andere blockiert — die wirksamste Einzelmaßnahme gegen Cross-Site Scripting (XSS). XSS ist seit über 20 Jahren einer der gefährlichsten Angriffsvektoren im Web und laut OWASP Top 10 weiterhin unter den Top 3 der Sicherheitsrisiken. Selbst wenn ein Angreifer eine XSS-Schwachstelle in Ihrem Code findet, verhindert CSP die Ausführung des eingeschleusten Codes. Der Wolf-Agents Web Security Scanner prüft Ihre CSP-Konfiguration auf 35 Einzelkriterien und zeigt konkret, welche Direktiven fehlen oder unsicher sind.
CSP ist der umfangreichste Security Header im Wolf-Agents Web Security Check — mit 35 von 166 Punkten hat er den größten Einfluss auf Ihre Gesamtnote. Trotzdem setzen viele Unternehmen CSP nicht oder nur unvollständig ein. Diese Anleitung zeigt, wie Sie CSP richtig implementieren.
Was passiert ohne CSP?
Ohne Content Security Policy hat der Browser keine Möglichkeit zu unterscheiden, welche Scripts legitim sind und welche von einem Angreifer eingeschleust wurden. Mit CSP definieren Sie explizit, was erlaubt ist.
Ohne CSP
- Angreifer können beliebigen JavaScript-Code auf Ihrer Website ausführen
- Session-Cookies können gestohlen werden (Session Hijacking)
- Keylogger können Eingaben abfangen — auch in Login-Formularen
- Website-Defacement und Phishing-Overlays werden ermöglicht
Mit CSP
- Browser blockiert nicht autorisierte Scripts automatisch
- Selbst bei XSS-Schwachstellen im Code bleibt die Seite geschützt
- Transparentes Violation-Reporting zeigt Angriffsversuche in Echtzeit
- Belastbarer Compliance-Nachweis für NIS2, PCI DSS und DSGVO-Audits
CSP in 3 Schritten implementieren
Die wichtigste Regel bei der CSP-Implementierung: Nie ohne Testen direkt scharf schalten. Beginnen Sie immer im Report-Only-Modus, analysieren Sie die Ergebnisse, und wechseln Sie erst zum Enforcement, wenn keine unerwarteten Violations mehr auftreten.
Report-Only Modus starten
Violations erkennen, ohne die Website zu beschädigen
Im Report-Only-Modus meldet der Browser CSP-Verstöße in der Konsole und an Ihren Reporting-Endpoint — blockiert aber nichts. So können Sie die Policy in Ruhe anpassen, ohne dass Ihre Website für Besucher kaputt geht.
# nginx.conf — Report-Only CSP zum Testen
add_header Reporting-Endpoints 'csp-endpoint="https://ihre-domain.de/api/csp-report"' always;
add_header Content-Security-Policy-Report-Only
"default-src 'self';
script-src 'self';
style-src 'self' 'unsafe-inline';
img-src 'self' data: https:;
report-uri /api/csp-report;
report-to csp-endpoint"
always;# .htaccess — Report-Only CSP zum Testen
<IfModule mod_headers.c>
Header always set Content-Security-Policy-Report-Only \
"default-src 'self'; script-src 'self'; \
style-src 'self' 'unsafe-inline'; \
img-src 'self' data: https:; \
report-uri /api/csp-report"
</IfModule>Detaillierte Nginx-Anleitung → · Anleitungen für weitere Stacks verfügbar
Violations analysieren und CSP anpassen
Browser DevTools + Reporting-Endpoint auswerten
Öffnen Sie die Browser DevTools (F12) → Console. CSP-Verstöße erscheinen als Warnungen. Passen Sie die Policy an, bis keine unerwarteten Violations mehr auftreten. Lassen Sie die Policy mindestens eine Woche im Report-Only-Modus.
| Violation | Lösung |
|---|---|
| Inline-Script blockiert | Nonce oder Hash hinzufügen |
| Externe Bibliothek blockiert | Domain zu script-src hinzufügen |
| Google Fonts blockiert | fonts.googleapis.com zu style-src, fonts.gstatic.com zu font-src |
| Analytics blockiert | *.google-analytics.com *.googletagmanager.com zu script-src |
Von Report-Only zu Enforcement wechseln
CSP scharf schalten und Violations aktiv blockieren
Wenn keine unerwarteten Violations mehr auftreten, ändern Sie den Header-Namen:
Content-Security-Policy-Report-Only → Content-Security-PolicyDie wichtigsten CSP-Direktiven
Jede CSP-Direktive kontrolliert eine bestimmte Ressourcen-Kategorie. Nicht aufgeführte Direktiven fallen auf default-src zurück — mit drei wichtigen Ausnahmen.
| Direktive | Kontrolliert | Empfehlung |
|---|---|---|
default-src | Fallback für alle Ressourcen | 'self' |
script-src | JavaScript-Dateien | 'self' + Nonces |
style-src | CSS-Dateien und Inline-Styles | 'self' 'unsafe-inline' |
img-src | Bilder und Favicons | 'self' data: https: |
font-src | Schriftarten (Webfonts) | 'self' + Font-CDNs |
connect-src | AJAX, Fetch, WebSocket, SSE | 'self' + API-Domains |
frame-ancestors | Wer darf diese Seite einbetten | 'self' |
object-src | Flash, Plugins, Embeds | 'none' |
base-uri | Basis-URL für relative Pfade | 'self' |
form-action | Erlaubte Formular-Ziele | 'self' |
base-uri, form-action und frame-ancestors erben nicht von default-src. Wenn Sie diese Direktiven nicht explizit setzen, gibt es für sie keinen Schutz — unabhängig davon, wie restriktiv Ihre default-src ist.
Nonces und strict-dynamic: CSP ohne Wartungsaufwand
Für maximale Sicherheit ersetzen Sie 'unsafe-inline' durch Nonces — einmalige Token, die bei jedem Request neu generiert werden. In Kombination mit strict-dynamic entfällt die Pflege von Domain-Whitelists vollständig: Scripts, die von einem vertrauenswürdigen Script geladen werden, erben automatisch das Vertrauen.
script-src 'self' 'nonce-abc123'
https://cdn.jsdelivr.net
https://unpkg.com
https://cdnjs.cloudflare.com
https://ajax.googleapis.com;script-src 'nonce-abc123'
'strict-dynamic';Nonces erfordern serverseitige Generierung — die genaue Implementierung hängt von Ihrem Stack ab. Nginx-Anleitung mit Nonces →
CSP und regulatorische Anforderungen
Content Security Policy gehört zum „Stand der Technik" bei der Absicherung von Webanwendungen. Mehrere Regulierungen fordern direkt oder indirekt den Einsatz von CSP — und machen den Header zu einem nachweisbaren Compliance-Baustein.
NIS2 / §30 BSIG
Maßnahme (e) fordert Sicherheit bei Erwerb, Entwicklung und Wartung von IT-Systemen — inklusive Security Headers. Die Geschäftsleitung haftet persönlich nach §38 BSIG.
NIS2-Checkliste ansehen →PCI DSS 4.0.1
Req. 6.4.3 fordert ein Script-Inventar, Req. 11.6.1 verlangt Tamper Detection für Payment-Seiten. CSP mit strict-dynamic erfüllt beide Anforderungen. Seit 31.03.2025 verpflichtend.
DSGVO Art. 32
„Geeignete technische Maßnahmen" zum Schutz personenbezogener Daten — CSP verhindert den Diebstahl von Nutzerdaten durch XSS-Angriffe und ist ein dokumentierbarer Nachweis bei Datenschutz-Audits.
Wie steht Ihre Domain bei Content Security Policy?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.
Häufig gestellte Fragen
Was ist Content Security Policy (CSP)?
Content Security Policy ist ein HTTP-Header, der dem Browser mitteilt, welche Ressourcen (Scripts, Styles, Bilder etc.) auf einer Seite geladen werden dürfen. CSP ist der wirksamste Schutz gegen Cross-Site Scripting (XSS) — den häufigsten Angriffsvektor im Web.
Schützt CSP vor allen XSS-Angriffen?
Eine korrekt konfigurierte CSP mit Nonces oder Hashes kann nahezu alle Formen von XSS verhindern. Gegen DOM-basiertes XSS bietet zusätzlich Trusted Types Schutz (CSP-Direktive require-trusted-types-for). CSP ist eine Defense-in-Depth-Maßnahme — sie sollte sichere Programmierung ergänzen, nicht ersetzen.
Kann CSP meine Website kaputt machen?
Ja, eine zu strenge CSP kann legitime Ressourcen blockieren. Deshalb sollten Sie immer mit Content-Security-Policy-Report-Only beginnen. In diesem Modus werden Violations gemeldet, aber nichts blockiert. Erst nach gründlichem Testen wechseln Sie zum Enforcement.
Was ist der Unterschied zwischen Report-Only und Enforcement?
Content-Security-Policy-Report-Only meldet Verstöße nur — der Browser blockiert nichts. Content-Security-Policy (ohne Report-Only) blockiert tatsächlich nicht-autorisierte Ressourcen. Starten Sie immer mit Report-Only, analysieren Sie die Violations, und wechseln Sie erst nach mindestens einer Woche ohne unerwartete Meldungen zum Enforcement.
Brauche ich CSP, wenn ich bereits eine WAF habe?
Ja. Eine Web Application Firewall (WAF) und CSP schützen auf verschiedenen Ebenen: Die WAF filtert bösartige Requests am Server, CSP kontrolliert was der Browser ausführen darf. Beide zusammen bilden Defense-in-Depth — WAF allein kann keinen clientseitigen XSS-Schutz bieten.
Ist CSP für NIS2-Compliance erforderlich?
CSP ist nicht explizit in NIS2 genannt, gehört aber zum „Stand der Technik" bei der Systemhärtung nach §30 BSIG Maßnahme (e). In Kombination mit anderen Security Headers bildet CSP einen technisch prüfbaren Nachweis für die geforderten Cybersicherheitsmaßnahmen. Wolf-Agents prüft Ihre CSP-Konfiguration als Teil des Web Security Checks.