Stell dir vor, jemand schleust auf deiner Website ein Skript ein, das alle Formulareingaben deiner Besucher mitliest – Passwörter, Kontaktdaten, Zahlungsinformationen. Deine WordPress-Installation läuft einwandfrei, das Plugin-Audit war sauber, und trotzdem passiert es. Solche Angriffe heißen Cross-Site Scripting, kurz XSS. Sie gehören seit Jahren zu den häufigsten Angriffsvektoren im Web – und ein korrekt gesetzter Content-Security-Policy-Header würde die meisten davon wirkungslos machen.
Mit dem kostenlosen CSP Generator von WP Helping Hand geht das jetzt direkt im Browser – keine Registrierung, keine Datenweitergabe, fertige Header-Zeile zum Kopieren.
Was ist ein Content-Security-Policy-Header?
Wenn ein Browser deine Website lädt, fragt er für jeden Inhalt nach: JavaScript, CSS, Bilder, Schriften, eingebettete Videos. Standardmäßig darf er das von überall laden. Der Content-Security-Policy-Header, kurz CSP, ändert das. Du sagst dem Browser damit ganz konkret: Skripte dürfen nur von meinem eigenen Server geladen werden. Alles andere: geblockt.
Die wichtigsten CSP-Direktiven für WordPress-Websites:
- default-src: Fallback für alle Inhaltstypen ohne eigene Direktive – Basis:
'self' - script-src: Steuert, woher JavaScript geladen werden darf
- style-src: Für CSS – Google Fonts braucht
https://fonts.googleapis.com - font-src: Für Schriftarten – bei Google Fonts:
https://fonts.gstatic.com - img-src: Für Bilder inkl. externer CDNs;
data:erlaubt Base64-Bilder - frame-src: Für iframes – YouTube braucht
https://www.youtube.com - connect-src: Für AJAX-Anfragen, WebSockets und API-Calls
- form-action: Legt fest, wohin Formulare Daten senden dürfen
Warum ist CSP für WordPress besonders relevant?
WordPress-Websites sind ein beliebtes Angriffsziel – nicht weil WordPress selbst unsicher ist, sondern weil so viele Plugins und Themes im Umlauf sind, von denen nicht alle gleich gut gepflegt werden. WordPress-Websites laden typischerweise Ressourcen aus vielen Quellen: Google Analytics, Google Fonts, YouTube-Embeds, CDN-Links für jQuery, Zahlungsanbieter wie Stripe oder PayPal. Jede dieser externen Quellen ist potenziell ein Einfallstor.
Die häufigsten Fehler bei CSP-Headern
Zu weit gefasste Direktiven: script-src * erlaubt Skripte von überall und macht den Header damit wirkungslos.
Fehlende Direktiven: Es gibt mehr als ein Dutzend CSP-Direktiven. Wer nur script-src setzt und den Rest vergisst, lässt Lücken.
unsafe-inline und unsafe-eval: Diese Werte erlauben Inline-Skripte und dynamische Code-Ausführung – genau das, was Angreifer ausnutzen wollen.
Falsche Syntax: Ein vergessenes Semikolon oder ein Tippfehler – und der Browser ignoriert den gesamten Header.
So funktioniert der CSP Generator von WP Helping Hand
Das Tool läuft vollständig im Browser. Es werden keine Daten an einen Server übertragen.
Schritt 1: Tool öffnen unter wp-helping-hand.com/tools/csp-generator/ – keine Anmeldung nötig.
Schritt 2: Direktiven konfigurieren – 'self' für eigene Inhalte, konkrete Domains für externe Quellen.
Schritt 3: Header generieren. Ergebnis-Beispiel:
Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: https:; frame-src 'none'Schritt 4: Header in WordPress einbinden via .htaccess, functions.php oder einem Security-Plugin.
Schritt 5: Testen – F12 öffnen → Console. Jede CSP-Verletzung wird direkt angezeigt.
Tipp: Starte mit dem Header im Report-Only-Modus (Content-Security-Policy-Report-Only). So blockiert der Header noch nichts, aber du siehst in der Konsole genau, was geblockt werden würde.
CSP-Header testen mit externen Tools
- SecurityHeaders.com – Analysiert alle HTTP-Sicherheitsheader und bewertet sie mit einer Schulnote
- Google Chrome DevTools – F12 → Console zeigt alle CSP-Verletzungen direkt
- CSP Evaluator (von Google) – Prüft eine CSP-Policy auf bekannte Schwachstellen
So setze ich CSP-Header bei meinen Wartungskunden um
Schritt 1 – Alle externen Quellen erfassen: Browser-Konsole unter „Network“ öffnen, jede relevante Seite laden und alle Domains notieren. Bei WordPress-Websites kommen dabei oft 10–20 verschiedene Domains zusammen.
Schritt 2 – CSP Generator konfigurieren: Alle Domains in die entsprechenden Direktiven eintragen. 'unsafe-inline' oder 'unsafe-eval' so weit wie möglich vermeiden.
Schritt 3 – Report-Only-Modus aktivieren: Content-Security-Policy-Report-Only setzen und alle Seiten durchklicken.
Schritt 4 – Auf echten CSP-Header umstellen: Erst wenn keine CSP-Verletzungen mehr erscheinen.
Schritt 5 – Finaler Test und SecurityHeaders.com: Ziel ist mindestens ein A, ideal ein A+.
Was der CSP-Header nicht ersetzt
Ein CSP-Header ist kein Allheilmittel. Er schützt vor einer bestimmten Klasse von Angriffen – vor allem XSS. Er ersetzt nicht:
- Regelmäßige Plugin- und Theme-Updates
- Starke Passwörter und Zwei-Faktor-Authentifizierung
- Regelmäßige Backups
- Eine Web Application Firewall
Fazit
Einen Content-Security-Policy-Header manuell aufzuschreiben war bisher der Part, den die meisten übersprungen haben. Der CSP Generator von WP Helping Hand macht das schneller. Du konfigurierst, du bekommst eine fertige Zeile, du bindest sie ein. Kein Login, keine Datenweitergabe, kein Abo.
