Content-Security-Policy in WordPress einrichten

Content-Security-Policy (CSP) ist einer der wirkungsvollsten verfügbaren Security-Header, aber gleichzeitig einer der schwierigsten, die man bei WordPress korrekt umsetzen kann. Der Grund ist einfach: WordPress-Core, Themes und Plugins verwenden alle gerne Inline-Skripte und -Styles. Eine strenge CSP blockiert diese standardmäßig, was bedeutet, dass deine Seite auf unerwartete Weise kaputtgehen kann, wenn du nicht sorgfältig planst. Diese Anleitung führt dich durch den gesamten Prozess, vom Verständnis dessen, was CSP bewirkt, bis zum Deployment einer produktionsreifen Policy.

Warum CSP bei WordPress besonders herausfordernd ist

Die meisten WordPress-Seiten setzen stark auf Muster, die CSP einschränken soll. Hier sind die häufigsten Probleme, auf die du stoßen wirst:

• Inline-Skripte: viele Plugins injizieren JavaScript direkt in den HTML-Code über <script>-Tags ohne src-Attribute. Page-Builder wie Elementor, WPBakery und Divi tun dies extensiv.
• Inline-Styles: der WordPress-Customizer, Gutenberg-Blöcke und die meisten Themes fügen style-Attribute oder <style>-Blöcke zur Seite hinzu. Eine strenge CSP ohne 'unsafe-inline' für Styles wird das visuelle Erscheinungsbild deiner Seite zerstören.
• eval()-Nutzung: manche Plugins verwenden JavaScripts eval()-Funktion oder ähnliche Konstrukte, was die 'unsafe-eval'-Direktive erfordert.
• Drittanbieter-Ressourcen: Google Analytics, Google Fonts, reCAPTCHA, eingebettete YouTube-Videos, Social-Media-Widgets. Jede davon braucht einen eigenen CSP-Eintrag.

Aufgrund all dessen solltest du niemals eine CSP von einer anderen Website kopieren und in deine WordPress-Konfiguration einfügen. Jede WordPress-Seite hat eine einzigartige Kombination aus Plugins und Themes, daher muss jede CSP individuell angepasst werden.

Mit Report-Only-Modus starten, um herauszufinden, was kaputtgehen würde

Der sicherste Einstieg ist mit dem Content-Security-Policy-Report-Only-Header. Dieser Header verhält sich genau wie CSP, blockiert aber tatsächlich nichts. Stattdessen protokolliert er Verstöße in der Browser-Konsole, damit du sehen kannst, was deine Policy verhindern würde. Nichts auf deiner Seite bricht, aber du erhältst volle Transparenz.

Füge dies zu deiner .htaccess-Datei hinzu (Apache):

<IfModule mod_headers.c>
    Header set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data: https://fonts.gstatic.com; connect-src 'self';"
</IfModule>

Oder für Nginx:

add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data: https://fonts.gstatic.com; connect-src 'self';" always;

Lass dies für mindestens einige Tage laufen und browse durch alle wichtigen Seiten deiner Website (Startseite, Blogbeiträge, Kontaktformular, WooCommerce-Checkout, falls zutreffend). Jede Seite kann unterschiedliche Plugins und Ressourcen laden.

CSP-Verstöße in der Browser-Konsole finden

Nach der Aktivierung des Report-Only-Modus öffne deine Seite in Chrome oder Firefox und drücke F12, um die DevTools zu öffnen. Gehe zum Konsole-Tab. CSP-Verstöße erscheinen als Warnmeldungen, die so aussehen:

[Report Only] Refused to load the script 'https://www.googletagmanager.com/gtag/js' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-inline'".

Jede Verstoßmeldung sagt dir genau, was blockiert wurde und welche Direktive den Verstoß verursacht hat. Sammle alle diese Meldungen und nutze sie, um deine Allowlist aufzubauen. Besuche jede wichtige Seite deiner Website, einschließlich Seiten mit Formularen, Slidern, Karten und jede Seite, die spezielle Plugins lädt.

Die wichtigsten CSP-Direktiven für WordPress verstehen

Hier sind die Direktiven, die du höchstwahrscheinlich konfigurieren musst:

• default-src: der Fallback für alle Ressourcentypen, die nicht explizit aufgeführt sind. Setze dies als Grundlage auf 'self'.
• script-src: kontrolliert, woher JavaScript geladen werden darf. Du wirst bei WordPress fast sicher 'unsafe-inline' brauchen. Wenn ein Plugin eval() verwendet, brauchst du zusätzlich 'unsafe-eval'.
• style-src: kontrolliert, woher CSS geladen werden darf. WordPress erfordert hier fast immer 'unsafe-inline'.
• img-src: kontrolliert Bildquellen. Verwende 'self' data: https:, um eigene Bilder, Data-URIs (von vielen Plugins verwendet) und alle Bilder über HTTPS zuzulassen.
• font-src: kontrolliert das Laden von Schriftarten. Wenn du Google Fonts verwendest, füge https://fonts.gstatic.com hinzu.
• connect-src: kontrolliert, wohin JavaScript Netzwerkanfragen stellen darf (AJAX, fetch, WebSocket). WordPress-Admin nutzt dies intensiv für die REST API und Heartbeat API.
• frame-src: kontrolliert, welche Domains in Iframes geladen werden dürfen. Nötig für YouTube-Einbettungen (https://www.youtube.com), Google Maps (https://www.google.com) und reCAPTCHA (https://www.google.com).
• object-src: kontrolliert Plugins wie Flash. Setze dies auf 'none', da Flash tot ist und diese Direktive hauptsächlich Legacy-Angriffsvektoren verhindert.

Die Policy Schritt für Schritt aufbauen

Beginne mit einer restriktiven Basis und füge Ausnahmen hinzu, wenn du Verstöße entdeckst:

1. Mit einer minimalen Policy beginnen: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self';
2. unsafe-inline für Skripte und Styles hinzufügen: das ist bei WordPress fast immer notwendig. script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';
3. data:-URIs für Bilder und Fonts hinzufügen: viele Plugins verwenden base64-kodierte Bilder. img-src 'self' data: https:; font-src 'self' data:;
4. Dein CDN whitelisten: wenn du ein CDN wie Cloudflare oder BunnyCDN nutzt, füge dessen Domain zu script-src, style-src, img-src und font-src hinzu.
5. Drittanbieter-Dienste einzeln hinzufügen: füge für jeden CSP-Verstoß in der Konsole die spezifische Domain zur passenden Direktive hinzu.

Häufige Allowlist-Einträge für WordPress-Seiten

Hier ist eine Referenz von Domains, die du für beliebte WordPress-Integrationen brauchen könntest:

• Google Fonts: style-src https://fonts.googleapis.com und font-src https://fonts.gstatic.com
• Google Analytics / GA4: script-src https://www.googletagmanager.com https://www.google-analytics.com und connect-src https://www.google-analytics.com https://analytics.google.com
• Google Maps: script-src https://maps.googleapis.com und frame-src https://www.google.com
• YouTube-Einbettungen: frame-src https://www.youtube.com https://www.youtube-nocookie.com
• reCAPTCHA: script-src https://www.google.com https://www.gstatic.com und frame-src https://www.google.com
• Gravatar: img-src https://secure.gravatar.com https://www.gravatar.com

Ein vollständiges WordPress-CSP-Beispiel

Hier ist eine realistische CSP für eine WordPress-Seite, die Google Analytics, Google Fonts, YouTube-Einbettungen und Gravatar verwendet. Passe sie an deine spezifischen Bedürfnisse an:

<IfModule mod_headers.c>
    Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://www.googletagmanager.com https://www.google-analytics.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https: https://secure.gravatar.com; font-src 'self' data: https://fonts.gstatic.com; connect-src 'self' https://www.google-analytics.com https://analytics.google.com; frame-src https://www.youtube.com https://www.youtube-nocookie.com; object-src 'none'; base-uri 'self'; form-action 'self';"
</IfModule>

WordPress-Plugins zur CSP-Verwaltung

Wenn sich die Bearbeitung von Server-Konfigurationsdateien einschüchternd anfühlt, können diese Plugins helfen:

• HTTP Headers: ein kostenloses Plugin, mit dem du alle Security-Header über den WordPress-Admin definieren kannst. Es unterstützt CSP mit einer benutzerfreundlichen Oberfläche, in der du Quellen pro Direktive hinzufügen kannst.
• Really Simple SSL Pro: enthält ein Content-Security-Policy-Modul mit Verstoß-Protokollierung und Ein-Klick-Lösungen für häufige Probleme.

Beachte, dass plugin-basierte CSP-Header nur für Seiten gesendet werden, die von WordPress verarbeitet werden. Statische Ressourcen, die direkt von deinem Webserver ausgeliefert werden, tragen den Header nicht. Für vollständigen Schutz ist die serverseitige Konfiguration vorzuziehen.

Vom Report-Only- in den Erzwingungsmodus wechseln

Sobald du mindestens eine Woche im Report-Only-Modus gelaufen bist und alle Verstöße behoben hast, bist du bereit zum Umschalten. Ändere einfach den Header-Namen von Content-Security-Policy-Report-Only zu Content-Security-Policy. Halte deine Browser-Konsole während der ersten Stunden offen und überwache auf Verstöße, die du möglicherweise übersehen hast. Wenn etwas kaputtgeht, kannst du jederzeit zum Report-Only-Modus zurückwechseln, während du das Problem behebst.

CSP mit InspectWP überprüfen

Nach der Implementierung deiner Content-Security-Policy führe einen neuen InspectWP-Scan durch. Der Bereich für Sicherheitsheader in deinem Report zeigt an, ob ein CSP-Header vorhanden ist und ob er sich im Report-Only- oder Erzwingungsmodus befindet. Nutze dies als schnelle Prüfung nach jeder Änderung, um zu bestätigen, dass deine Policy weiterhin korrekt gesendet wird.