Content-Security-Policy in WordPress einrichten

Content-Security-Policy (CSP) ist einer der wirkungsvollsten verfuegbaren 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 standardmaessig, was bedeutet, dass deine Seite auf unerwartete Weise kaputtgehen kann, wenn du nicht sorgfaeltig planst. Diese Anleitung fuehrt dich durch den gesamten Prozess, vom Verstaendnis 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 einschraenken soll. Hier sind die haeufigsten Probleme, auf die du stossen wirst:

• Inline-Skripte: viele Plugins injizieren JavaScript direkt in den HTML-Code ueber <script>-Tags ohne src-Attribute. Page-Builder wie Elementor, WPBakery und Divi tun dies extensiv.
• Inline-Styles: der WordPress-Customizer, Gutenberg-Bloecke und die meisten Themes fuegen style-Attribute oder <style>-Bloecke zur Seite hinzu. Eine strenge CSP ohne 'unsafe-inline' fuer Styles wird das visuelle Erscheinungsbild deiner Seite zerstoeren.
• eval()-Nutzung: manche Plugins verwenden JavaScripts eval()-Funktion oder aehnliche 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 einfuegen. 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 wuerde

Der sicherste Einstieg ist mit dem Content-Security-Policy-Report-Only-Header. Dieser Header verhaelt sich genau wie CSP, blockiert aber tatsaechlich nichts. Stattdessen protokolliert er Verstoesse in der Browser-Konsole, damit du sehen kannst, was deine Policy verhindern wuerde. Nichts auf deiner Seite bricht, aber du erhaeltst volle Transparenz.

Fuege 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 fuer 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 fuer mindestens einige Tage laufen und browse durch alle wichtigen Seiten deiner Website (Startseite, Blogbeitraege, Kontaktformular, WooCommerce-Checkout falls zutreffend). Jede Seite kann unterschiedliche Plugins und Ressourcen laden.

CSP-Verstoesse in der Browser-Konsole finden

Nach der Aktivierung des Report-Only-Modus oeffne deine Seite in Chrome oder Firefox und druecke F12, um die DevTools zu oeffnen. Gehe zum Konsole-Tab. CSP-Verstoesse 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 Verstoessmeldung sagt dir genau, was blockiert wurde und welche Direktive den Verstoss verursacht hat. Sammle alle diese Meldungen und nutze sie, um deine Allowlist aufzubauen. Besuche jede wichtige Seite deiner Website, einschliesslich Seiten mit Formularen, Slidern, Karten und jede Seite, die spezielle Plugins laedt.

Die wichtigsten CSP-Direktiven fuer WordPress verstehen

Hier sind die Direktiven, die du hoechstwahrscheinlich konfigurieren musst:

• default-src: der Fallback fuer alle Ressourcentypen, die nicht explizit aufgefuehrt 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 zusaetzlich '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 ueber HTTPS zuzulassen.
• font-src: kontrolliert das Laden von Schriftarten. Wenn du Google Fonts verwendest, fuege https://fonts.gstatic.com hinzu.
• connect-src: kontrolliert, wohin JavaScript Netzwerkanfragen stellen darf (AJAX, fetch, WebSocket). WordPress-Admin nutzt dies intensiv fuer die REST API und Heartbeat API.
• frame-src: kontrolliert, welche Domains in Iframes geladen werden duerfen. Noetig fuer 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 hauptsaechlich Legacy-Angriffsvektoren verhindert.

Die Policy Schritt fuer Schritt aufbauen

Beginne mit einer restriktiven Basis und fuege Ausnahmen hinzu, wenn du Verstoesse entdeckst:

1. Mit einer minimalen Policy beginnen: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self';
2. unsafe-inline fuer Skripte und Styles hinzufuegen: das ist bei WordPress fast immer notwendig. script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';
3. data:-URIs fuer Bilder und Fonts hinzufuegen: 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, fuege dessen Domain zu script-src, style-src, img-src und font-src hinzu.
5. Drittanbieter-Dienste einzeln hinzufuegen: fuege fuer jeden CSP-Verstoss in der Konsole die spezifische Domain zur passenden Direktive hinzu.

Haeufige Allowlist-Eintraege fuer WordPress-Seiten

Hier ist eine Referenz von Domains, die du fuer beliebte WordPress-Integrationen brauchen koenntest:

• 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 vollstaendiges WordPress-CSP-Beispiel

Hier ist eine realistische CSP fuer eine WordPress-Seite, die Google Analytics, Google Fonts, YouTube-Einbettungen und Gravatar verwendet. Passe sie an deine spezifischen Beduerfnisse 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 einschuechternd anfuehlt, koennen diese Plugins helfen:

• HTTP Headers: ein kostenloses Plugin, mit dem du alle Security-Header ueber den WordPress-Admin definieren kannst. Es unterstuetzt CSP mit einer benutzerfreundlichen Oberflaeche, in der du Quellen pro Direktive hinzufuegen kannst.
• Really Simple SSL Pro: enthaelt ein Content-Security-Policy-Modul mit Verstoss-Protokollierung und Ein-Klick-Loesungen fuer haeufige Probleme.

Beachte, dass plugin-basierte CSP-Header nur fuer Seiten gesendet werden, die von WordPress verarbeitet werden. Statische Ressourcen, die direkt von deinem Webserver ausgeliefert werden, tragen den Header nicht. Fuer vollstaendigen 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 Verstoesse behoben hast, bist du bereit zum Umschalten. Aendere einfach den Header-Namen von Content-Security-Policy-Report-Only zu Content-Security-Policy. Halte deine Browser-Konsole waehrend der ersten Stunden offen und ueberwache auf Verstoesse, die du moeglicherweise uebersehen hast. Wenn etwas kaputtgeht, kannst du jederzeit zum Report-Only-Modus zurueckwechseln, waehrend du das Problem behebst.

CSP mit InspectWP ueberpruefen

Nach der Implementierung deiner Content-Security-Policy fuehre einen neuen InspectWP-Scan durch. Der Bereich fuer 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 Pruefung nach jeder Aenderung, um zu bestaetigen, dass deine Policy weiterhin korrekt gesendet wird.