WordPress „Blocked by Content Security Policy“ beheben – CSP für WP sauber konfigurieren

Du sitzt gemütlich am Rechner, willst gerade ein neues WordPress-Plugin testen oder ein schickes Skript einbinden – und plötzlich: „Blocked by Content Security Policy“. Zack, Feierabend! Die Seite lädt nicht richtig, Bilder fehlen, das Kontaktformular ist tot. Willkommen im Club der CSP-Geplagten! Aber keine Sorge, du bist nicht allein. Und noch besser: Es gibt Lösungen, die nicht nur funktionieren, sondern auch deine Website sicherer und performanter machen. In diesem Artikel tauchen wir tief ein in die Welt der Content Security Policy (CSP) für WordPress, erklären, warum sie so wichtig ist, wie du sie richtig konfigurierst und wie du die nervigen Fehlermeldungen endgültig loswirst. Also, Kaffee bereitstellen – jetzt wird’s nerdig, aber auch unterhaltsam!

Content Security Policy – das klingt erstmal nach Bürokratie und Paragrafenreiterei, ist aber in Wahrheit ein mächtiges Werkzeug, um deine Website vor Angriffen wie Cross-Site Scripting (XSS) und Data Injection zu schützen. Laut OWASP Top 10 gehören XSS-Angriffe zu den häufigsten Sicherheitslücken im Web. Eine sauber konfigurierte CSP kann bis zu 90% der XSS-Angriffe verhindern (MDN Web Docs).

Doch wie so oft im Leben: Wo viel Schutz, da auch viel Potenzial für Chaos. Gerade bei WordPress, mit seinen unzähligen Plugins, Themes und externen Skripten, kann eine zu strenge oder falsch konfigurierte CSP schnell zum Showstopper werden. Plötzlich blockiert der Browser wichtige Ressourcen – und du stehst vor einem Rätsel. Lass uns gemeinsam herausfinden, wie du CSP für WordPress richtig, sicher und alltagstauglich einsetzt!

• Was ist die Content Security Policy (CSP)?
  
  Die CSP ist eine HTTP-Header-basierte Sicherheitsrichtlinie, die dem Browser sagt, welche Ressourcen (Skripte, Styles, Bilder, Fonts, etc.) geladen werden dürfen – und welche nicht. Sie ist quasi der Türsteher deiner Website: „Du kommst hier rein, du nicht!“ Das Ziel: Schadcode draußen halten, legitime Inhalte reinlassen.
• Warum ist CSP für WordPress besonders knifflig?
  
  WordPress lebt von Erweiterbarkeit. Plugins, Themes, externe Dienste wie Google Fonts, Analytics, YouTube – sie alle wollen irgendwas nachladen. Eine zu enge CSP blockiert schnell wichtige Funktionen. Eine zu lockere CSP öffnet Tür und Tor für Angreifer. Die Kunst liegt im perfekten Mittelweg.
• Typische Fehlermeldung: „Blocked by Content Security Policy“
  
  Diese Meldung taucht in der Browser-Konsole auf, wenn eine Ressource geladen werden soll, die nicht in der CSP erlaubt ist. Das kann ein Skript, ein Bild, ein Font oder sogar ein Inline-Style sein. Die Folge: Die Seite sieht kaputt aus oder funktioniert nicht mehr richtig.

Wie sieht eine CSP aus? Hier ein Beispiel für einen CSP-Header:


Content-Security-Policy: default-src 'self'; script-src 'self' https://www.google-analytics.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:;


Klingt erstmal kryptisch, ist aber logisch aufgebaut. Lass uns die wichtigsten Direktiven im Detail anschauen:

Wichtige Fakten:

• Seit 2012 ist CSP ein offizieller Webstandard (W3C).
• Alle modernen Browser unterstützen CSP (Chrome, Firefox, Edge, Safari).
• WordPress selbst liefert keine CSP aus – du bist also selbst verantwortlich!

Wie kommt die CSP auf deine WordPress-Seite? Es gibt drei Wege:

• Per .htaccess (Apache)
  Füge den CSP-Header direkt in deine .htaccess ein. Beispiel:
  
  
<IfModule mod_headers.c>
Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://www.google-analytics.com;"
</IfModule>

  
  Vorteil: Schnell, serverseitig, unabhängig von WordPress. Nachteil: Fehlerhafte Syntax = Website down!
• Per Plugin
  Es gibt Plugins wie HTTP Headers oder WP Content Security Policy, die dir eine grafische Oberfläche bieten. Vorteil: Einfach, kein Code nötig. Nachteil: Plugins können veraltet sein oder Konflikte verursachen.
• Per functions.php
  Du kannst den Header auch per PHP setzen:
  
  
add_action('send_headers', function() {
header("Content-Security-Policy: default-src 'self'; script-src 'self' https://www.google-analytics.com;");
});

  
  Vorteil: Flexibel, direkt im Theme/Child-Theme. Nachteil: Fehlerhafte Header können schwer zu debuggen sein.

Die häufigsten CSP-Probleme bei WordPress – und wie du sie löst:

• Externe Skripte (Google Analytics, YouTube, reCAPTCHA)
  Viele Plugins laden Skripte von externen Domains. Diese müssen explizit in script-src erlaubt werden. Beispiel:
  
  
script-src 'self' https://www.google-analytics.com https://www.youtube.com https://www.gstatic.com;

  
  Tipp: Prüfe in der Browser-Konsole, welche Domains blockiert werden, und ergänze sie gezielt.
• Inline-Skripte und Styles
  WordPress und viele Themes nutzen Inline-JavaScript und -CSS. Standardmäßig blockiert CSP das. Lösung: 'unsafe-inline' erlauben – aber Vorsicht, das schwächt die Sicherheit! Besser: nonce-basierte Freigabe (siehe unten).
• Fonts und Icons (Google Fonts, Font Awesome)
  Fonts werden oft von fonts.gstatic.com geladen. Ergänze:
  
  
font-src 'self' https://fonts.gstatic.com;

  
  Für Font Awesome ggf. auch use.fontawesome.com erlauben.
• Bilder von externen Quellen
  Wenn du Bilder von anderen Domains einbindest (z.B. CDN, Unsplash), müssen diese in img-src stehen.
• AJAX- und API-Requests
  Plugins wie Contact Form 7 oder WooCommerce nutzen AJAX. Erlaube die API-Domains in connect-src.

Best Practice: CSP mit Nonces und Hashes

• Nonces (Number used once) sind einmalige Tokens, die du Inline-Skripten zuweist. Beispiel:
  
  
<script nonce="abc123">alert('Hi!');</script>

  
  Im Header:
  
  
Content-Security-Policy: script-src 'self' 'nonce-abc123';

  
  Vorteil: Nur Skripte mit dem richtigen Nonce werden ausgeführt. Nachteil: In WordPress nicht trivial umzusetzen, da viele Plugins Inline-Skripte dynamisch generieren.
• Hashes erlauben bestimmte Inline-Skripte per SHA-256-Hash. Beispiel:
  
  
Content-Security-Policy: script-src 'self' 'sha256-AbCdEf123...';

  
  Vorteil: Sehr sicher, aber aufwendig, da du für jedes Inline-Skript den Hash berechnen musst.

Debugging: So findest du CSP-Fehler

• Browser-Konsole öffnen (F12) und auf „Console“ oder „Security“ achten. Hier siehst du, welche Ressourcen blockiert werden und warum.
• Report-Only-Modus nutzen: Setze den Header als Content-Security-Policy-Report-Only. So werden Verstöße nur gemeldet, aber nicht blockiert. Perfekt zum Testen!
• Online-Tools wie CSP Evaluator oder Report URI helfen beim Analysieren und Optimieren deiner CSP.

Schritt-für-Schritt-Anleitung: CSP für WordPress sauber konfigurieren

1. Bestandsaufnahme machen: Welche externen Ressourcen nutzt deine Seite? (Google Fonts, Analytics, YouTube, Social Media, CDNs, etc.)
2. Testweise eine restriktive CSP setzen:
   
   
Content-Security-Policy: default-src 'self';

   
   Prüfe, was alles kaputtgeht.
3. Fehlermeldungen auswerten: Öffne die Browser-Konsole, notiere blockierte Domains und Ressourcen.
4. CSP schrittweise erweitern: Erlaube gezielt die benötigten Domains für script-src, style-src, img-src usw.
5. Report-Only-Modus nutzen: Teste die neue CSP, ohne dass sie blockiert. So kannst du Fehlerquellen identifizieren, ohne die Seite zu zerschießen.
6. Finale CSP aktivieren: Wenn alles läuft, setze die CSP produktiv.
7. Regelmäßig prüfen: Bei neuen Plugins/Themes oder Updates kann sich der Ressourcenbedarf ändern. Passe die CSP bei Bedarf an.

Beispiel für eine alltagstaugliche WordPress-CSP:


Content-Security-Policy:
default-src 'self';
script-src 'self' 'unsafe-inline' https://www.google-analytics.com https://www.googletagmanager.com https://www.gstatic.com https://www.recaptcha.net;
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
img-src 'self' data: https://www.google-analytics.com;
font-src 'self' https://fonts.gstatic.com;
connect-src 'self' https://api.yourdomain.com;


Wichtige Hinweise:

• ‚unsafe-inline‘ ist ein Kompromiss für WordPress, aber nicht optimal. Besser: Nonces oder Hashes, wenn möglich.
• Jede Website ist anders! Passe die CSP immer individuell an deine Plugins, Themes und externen Dienste an.
• Testen, testen, testen! CSP ist mächtig, aber unforgiving. Ein kleiner Fehler – und die Seite ist kaputt.

Fazit: CSP ist Pflicht, aber kein Hexenwerk!

Mit einer gut konfigurierten Content Security Policy schützt du deine WordPress-Seite effektiv vor vielen Angriffen – und das ganz ohne Performanceverlust. Klar, der Weg dahin ist manchmal steinig, aber mit Geduld, System und ein bisschen Nerd-Power klappt’s. Und falls du keine Lust auf stundenlanges Debugging hast, gibt’s ja noch uns!

Nakaryu – Deine WordPress-Profis aus Nürnberg

Wir bei Nakaryu lieben nicht nur schönes Design, sondern auch sauberen, sicheren Code. Ob CSP-Konfiguration, DSGVO-Check oder Performance-Optimierung – wir machen deine Website fit für die Zukunft. Und das Beste: Mit unserer Webdesign-Flatrate bekommst du alles aus einer Hand – zum monatlichen Fixpreis, ohne Risiko. Klingt gut? Dann lass uns gemeinsam deine Website sicher, schnell und einzigartig machen!

Quellen:

• OWASP Top 10
• MDN Web Docs: Content Security Policy (CSP)
• W3C: Content Security Policy Level 3
• CSP Evaluator (Google)
• Report URI: CSP Generator