Content-Security-Policy

Was ist Content-Security-Policy?

Content-Security-Policy (CSP) ist ein HTTP-Response-Header, mit dem ein Webserver dem Browser mitteilt, welche Quellen für Scripts, Stylesheets, Bilder und andere Ressourcen zugelassen sind. Der Browser verweigert das Laden oder Ausführen aller Ressourcen, die nicht explizit erlaubt wurden. CSP ist die wichtigste technische Schutzmaßnahme gegen XSS (Cross-Site Scripting) — und sie wirkt auf der letzten Verteidigungslinie: direkt im Browser des Besuchers.

Ohne CSP kann jeder Script-Code, den ein Angreifer in eine Seite einschleust, ungehindert ausgeführt werden — ob über ein Kommentarfeld, eine unsichere Eingabe oder eine kompromittierte Drittanbieter-Ressource. Mit einer restriktiven CSP ist selbst ein erfolgreicher Injektionsangriff weitgehend wirkungslos, weil der Browser die Ausführung des eingeschleusten Codes verweigert.

Wie funktioniert Content-Security-Policy?

Der Server sendet beim Ausliefern einer HTML-Seite einen HTTP-Header in dieser Form:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; img-src *;

Dieser Header enthält eine Liste von Direktiven, die jeweils einen Ressourcentyp regeln:

• default-src — Fallback für alle nicht explizit genannten Typen
• script-src — Woher darf JavaScript geladen werden?
• style-src — Woher dürfen Stylesheets kommen?
• img-src — Woher dürfen Bilder geladen werden?
• connect-src — Wohin darf JavaScript HTTP-Anfragen senden?
• frame-ancestors — Wer darf diese Seite in einen <iframe> einbetten (Schutz gegen Clickjacking)

Für Script-Quellen gibt es neben Domains auch besondere Schlüsselwörter: 'self' (nur die eigene Domain), 'none' (gar nichts), 'unsafe-inline' (Inline-Scripts erlaubt — schwächt CSP massiv), 'nonce-{zufallswert}' (erlaubt einen spezifischen Script-Block per Einmal-Token) und 'strict-dynamic' (vertraut Scripts, die von bereits erlaubten Scripts geladen werden).

Der Browser prüft bei jedem Ressourcen-Ladeversuch, ob die Quelle der CSP entspricht. Verstöße werden in der Browser-Konsole protokolliert und — je nach Konfiguration — auch an einen Server-Endpunkt gemeldet (report-uri oder report-to Direktive).

Report-Only-Modus: CSP lässt sich mit dem Header Content-Security-Policy-Report-Only im "Beobachtungsmodus" deployen: Verstöße werden gemeldet, aber nicht geblockt. Das erlaubt eine sichere Einführung ohne sofortige Produktionsunterbrechungen.

Content-Security-Policy in der WordPress-Praxis

WordPress stellt bei der CSP-Einführung besondere Herausforderungen: Der Editor (Gutenberg), viele Plugins und das Admin-Backend verwenden Inline-Scripts und laden Ressourcen von diversen Drittquellen. Eine strikte script-src 'self'-Direktive bricht WordPress typischerweise sofort.

Der pragmatische Ansatz für WordPress-Projekte:

Schritt 1 — Report-Only einschalten:

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

Schritt 2 — Verletzungen sammeln: Über einen Zeitraum von 1-2 Wochen alle report-uri-Reports auswerten. Was lädt dein WordPress woher?

Schritt 3 — Policy verfeinern: Erlaubte externe Quellen (Google Fonts, Analytics, CDNs) explizit aufnehmen. Für den Admin-Bereich kann eine separatere, weniger restriktive Policy gesetzt werden.

Schritt 4 — Nonces für Inline-Scripts: WordPress unterstützt ab Version 6.x das Injizieren von CSP-Nonces über den Filter wp_csp_policies. Damit werden erlaubte Inline-Scripts mit Einmal-Tokens versehen, anstatt 'unsafe-inline' global zu erlauben.

Typische Fehlkonfigurationen:

• 'unsafe-inline' und 'unsafe-eval' erlauben: Hebt den XSS-Schutz praktisch auf
• Nur den Frontend-Bereich schützen, aber /wp-admin vergessen
• data: in img-src ohne Einschränkung: Kann für Script-Injection missbraucht werden
• CSP nur per <meta>-Tag statt HTTP-Header: frame-ancestors funktioniert nur im Header

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-{RANDOM}' https://www.google-analytics.com;
  style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
  img-src 'self' data: https:;
  font-src 'self' https://fonts.gstatic.com;
  connect-src 'self' https://www.google-analytics.com;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';

Was passiert ohne oder mit fehlerhafter Content-Security-Policy?

Ohne CSP hat ein erfolgreicher XSS-Angriff freie Bahn: Der eingeschleuste Script-Code läuft im Sicherheitskontext der Website und kann Session-Cookies stehlen, Tastatureingaben mitschneiden (Keylogging), die Seite manipulieren (Phishing-Formulare einblenden), die Webcam anfordern oder den Browser als Angriffswerkzeug gegen andere Systeme nutzen.

Fehlerhafte CSP-Konfigurationen sind fast so schlimm wie keine CSP: Eine Policy mit 'unsafe-inline' erlaubt XSS wieder durch die Hintertür. Eine zu permissive default-src *-Direktive gibt Angreifern alle Freiheit, ihre Payloads von externen Servern nachzuladen.

Reale Schadensfälle betreffen regelmäßig auch große Plattformen — nicht weil CSP fehlt, sondern weil sie so konfiguriert wurde, dass sie den Betrieb nicht stört, aber den Angriff auch nicht verhindert.

Häufige Fragen

Reicht ein CSP-Header für vollständigen XSS-Schutz? Nein. CSP ist eine wichtige zusätzliche Schutzschicht, ersetzt aber keine Input-Validierung und Output-Encoding. Der richtige Ansatz ist Defence in Depth: zuerst XSS durch sichere Programmierung verhindern, dann CSP als Auffangnetz für Fälle, die trotzdem durchrutschen.

Gilt CSP auch für den WordPress-Adminbereich? Ja — und er ist besonders wichtig dort, weil ein XSS im Admin einem Angreifer faktisch vollen Zugriff auf WordPress gibt. Allerdings ist eine strikte CSP im Admin-Backend durch die Komplexität des Gutenberg-Editors schwieriger umzusetzen.

Was ist der Unterschied zwischen CSP und einem WAF? Eine Web Application Firewall (WAF) filtert HTTP-Anfragen serverseitig und versucht, Angriffe vor dem Erreichen der Anwendung zu blockieren. CSP arbeitet clientseitig im Browser und greift, nachdem die Antwort ausgeliefert wurde. Beide ergänzen sich — keines ersetzt das andere.

Verwandte Begriffe

HSTS · MIME-Sniffing