Content Security Policy Generator für WordPress – kostenlos & ohne Anmeldung
Das Problem: Einen CSP-Header richtig aufzusetzen ist aufwendig. Wer macht das schon manuell? Mit dem kostenlosen CSP Generator von WP Helping Hand geht das jetzt direkt im Browser – keine Registrierung, keine Datenweitergabe, fertige Header-Zeile zum Kopieren.
In diesem Artikel erkläre ich dir, was ein Content-Security-Policy-Header ist, warum er für WordPress besonders wichtig ist, und wie du das Tool in ein paar Minuten nutzt.
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 – von deinem Server, von Google, von irgendeiner externen Domain, die vielleicht irgendwo in einem Plugin steckt.
Der Content-Security-Policy-Header, kurz CSP, ändert das. Du sagst dem Browser damit ganz konkret: Skripte dürfen nur von meinem eigenen Server und von cdn.example.com geladen werden. Styles nur von dort und dort. Bilder von überall. Fonts nur von Google Fonts. Alles andere: geblockt.
Das klingt nach einem kleinen technischen Detail. Ist es aber nicht. Wenn ein Angreifer es schafft, ein fremdes Skript auf deiner Seite einzuschleusen – durch eine Sicherheitslücke in einem Plugin, einen kompromittierten Drittanbieter oder ein manipuliertes Kommentarfeld – dann verhindert der CSP-Header, dass dieses Skript im Browser des Besuchers ausgeführt wird. Der Angriff trifft auf eine Wand.
Die wichtigsten CSP-Direktiven für WordPress-Websites auf einen Blick:
- default-src: Fallback für alle Inhaltstypen ohne eigene Direktive – Basis:
'self' - script-src: Steuert, woher JavaScript geladen werden darf (z. B. Google Tag Manager)
- 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. Eine bekannte Sicherheitslücke in einem Plugin, das noch auf tausenden Websites aktiv ist: Das ist der Alltag in der WordPress-Welt.
Dazu kommt: WordPress-Websites laden typischerweise Ressourcen aus vielen Quellen. Google Analytics, Google Fonts, YouTube-Embeds, CDN-Links für jQuery, Zahlungsanbieter wie Stripe oder PayPal, Social-Media-Widgets. Jede dieser externen Quellen ist potenziell ein Einfallstor, wenn die Quelle selbst kompromittiert wird oder ein Angreifer eine ähnliche Domain registriert.
Ein CSP-Header kontrolliert genau das. Er legt fest, welchen Quellen dein Browser vertraut – und blockiert alles andere automatisch.
Die häufigsten Fehler bei CSP-Headern – und warum ein Generator hilft
Wer einen CSP-Header manuell schreibt, macht fast immer einen dieser Fehler:
Zu weit gefasste Direktiven: script-src * erlaubt Skripte von überall und macht den Header damit wirkungslos. Kommt öfter vor als man denkt, weil irgendwas auf der Website sonst bricht.
Fehlende Direktiven: Es gibt mehr als ein Dutzend CSP-Direktiven – für Skripte, Styles, Bilder, Fonts, Frames, Formularziele, WebSockets und mehr. Wer nur script-src setzt und den Rest vergisst, lässt Lücken.
unsafe-inline und unsafe-eval: Diese Werte in der script-src oder style-src erlauben Inline-Skripte und dynamische Code-Ausführung. Viele WordPress-Plugins brauchen das – aber gleichzeitig ist es das, was Angreifer ausnutzen. Ein guter CSP Generator zeigt dir, wo diese Kompromisse liegen.
Falsche Syntax: Ein vergessenes Semikolon, ein Tippfehler in einer Domain, ein fehlender https:-Prefix – und der Browser ignoriert den gesamten Header oder blockiert Inhalte, die er nicht blockieren soll.
Ein Generator nimmt dir die Syntax-Arbeit ab. Du wählst, was du erlauben willst, und bekommst eine fertige Zeile raus.
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
Öffne den CSP Generator auf wp-helping-hand.com. Keine Anmeldung, keine E-Mail-Adresse.
Schritt 2: Direktiven konfigurieren
Das Tool zeigt dir die wichtigsten CSP-Direktiven in einer übersichtlichen Oberfläche. Für jede Direktive kannst du festlegen: 'self' für Inhalte nur vom eigenen Server, konkrete Domains wie https://fonts.googleapis.com für Google Fonts, oder Spezialwerte wie 'none' (alles blockieren) bzw. 'unsafe-inline' (wenn ein Plugin es wirklich braucht). Du musst kein CSP-Experte sein – das Tool führt dich durch die gängigen Direktiven und erklärt kurz, wofür jede steht.
Header generieren und in WordPress einbinden
Schritt 3: Header generieren
Ein Klick auf „Generieren" und das Tool gibt dir eine fertige Content-Security-Policy-Headerzeile aus. Zum 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
Du hast verschiedene Möglichkeiten, den Header zu setzen:
- Via .htaccess (Apache):
Header always set Content-Security-Policy "default-src 'self'; ..." - Via functions.php: Mit
add_action('send_headers', ...)und dem generierten Header-String - Via Security-Plugin: Tools wie Really Simple Security, Wordfence oder ein dediziertes Security-Header-Plugin erlauben dir, den generierten Header direkt einzutragen
Testen, anpassen und fertig – Schritt 5
Nach dem Einbinden öffnest du die Browser-Konsole (F12 → Console) und lädst deine Website. Der Browser zeigt dir dort, wenn etwas durch den CSP-Header geblockt wurde – inklusive der Domain, die du eventuell noch erlauben musst.
Kurze Anpassung im Generator, neue Headerzeile kopieren, einbinden – fertig. Dieser Testdurchlauf ist wichtig, weil jede WordPress-Installation unterschiedliche externe Quellen nutzt. Was auf einer Website funktioniert, muss auf deiner noch nicht passen.
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. Erst wenn du sicher bist, dass alles passt, wechselst du auf den echten Content-Security-Policy-Header.
Für wen ist der CSP Generator gedacht?
Der CSP Generator ist nützlich für alle, die eine WordPress-Website betreiben oder pflegen – unabhängig vom technischen Hintergrund. Du brauchst kein Programmierer zu sein, um das Tool zu nutzen. Du brauchst auch kein tiefes Verständnis von HTTP-Headern.
Besonders nützlich ist es für:
- WordPress-Freelancer und Agenturen, die Sicherheits-Audits für Kundenseiten machen und schnell einen passenden CSP-Header generieren wollen
- Webmaster, die ihre Website absichern wollen, ohne erst ein Studium in Web-Security absolvieren zu müssen
- Entwickler, die einen Starting-Point für komplexere CSP-Konfigurationen brauchen
- Alle, die auf SecurityHeaders.com eine schlechte Bewertung bekommen haben und gezielt nachbessern wollen
Was der CSP-Header nicht ersetzt
Kurze Einordnung, weil das manchmal missverstanden wird: Ein CSP-Header ist kein Allheilmittel. Er schützt vor einer bestimmten Klasse von Angriffen – vor allem XSS und Content Injection. Er ersetzt nicht:
- Regelmäßige Plugin- und Theme-Updates
- Starke Passwörter und Zwei-Faktor-Authentifizierung
- Regelmäßige Backups
- Eine Web Application Firewall
Sicherheit ist ein Schichtenmodell. Der CSP-Header ist eine wichtige Schicht – aber eben eine von mehreren. Wer alle Schichten sauber umsetzt, macht es Angreifern deutlich schwerer.
Welche Direktiven sind für WordPress-Websites wichtig?
Hier ein ausführlicher Überblick über die Direktiven, die du für eine typische WordPress-Website brauchst:
default-src – Der Fallback für alle Inhaltstypen, die keine eigene Direktive haben. Setz das auf 'self' als Ausgangsbasis.
script-src – Steuert, woher JavaScript geladen werden darf. Wichtig: Wenn du Google Analytics, Google Tag Manager oder andere externe Skripte einbindest, müssen deren Domains hier stehen.
style-src – Für CSS. Google Fonts braucht hier https://fonts.googleapis.com.
font-src – Für Schriftarten. Bei Google Fonts kommt https://fonts.gstatic.com dazu.
img-src – Für Bilder. Wenn du Bilder von externen CDNs oder sozialen Netzwerken einbindest, müssen die hier stehen. data: erlaubt Base64-kodierte Bilder, die manche Plugins nutzen.
frame-src – Für iframes. YouTube-Einbettungen brauchen https://www.youtube.com. Wenn du keine Frames brauchst: 'none'.
connect-src – Für AJAX-Anfragen, WebSockets und API-Calls. Relevant, wenn du externe APIs einbindest.
form-action – Legt fest, wohin Formulare Daten senden dürfen. 'self' reicht für die meisten WordPress-Formulare.
CSP-Header testen mit externen Tools
Nachdem du deinen CSP-Header eingebunden hast, empfiehlt sich ein Blick auf externe Testtools. Die bekanntesten:
SecurityHeaders.com – Analysiert alle HTTP-Sicherheitsheader deiner Website und bewertet sie mit einer Schulnote von A+ bis F. Du siehst auf einen Blick, welche Header fehlen und wie dein CSP bewertet wird.
Google Chrome DevTools – Öffne F12 → Console und lade deine Seite. Jede CSP-Verletzung wird direkt angezeigt – inklusive der blockierten Domain. So findest du fehlende Einträge in deiner Policy ohne langes Suchen.
CSP Evaluator (von Google) – Prüft eine CSP-Policy auf bekannte Schwachstellen und Konfigurationsfehler, bevor du sie live schaltest.
Diese Tools ergänzen den Generator perfekt: Generator für die Erstellung, externe Tools für die Verifikation.
Wie macht ein CSP-Header deine WordPress-Website konkret besser?
Ein korrekt konfigurierter Content-Security-Policy-Header wirkt sich auf vier Bereiche aus:
Schutz vor XSS-Angriffen: Das ist die Kernaufgabe. Selbst wenn ein Angreifer ein Skript einschleust, blockiert der Browser dessen Ausführung – weil die Domain nicht auf der Whitelist steht. Deine Besucher sind geschützt, auch wenn eine Lücke in einem Plugin ausgenutzt wird.
Bessere Sicherheitsbewertungen: Tools wie SecurityHeaders.com und der Google PSI-Bericht berücksichtigen Sicherheitsheader. Eine gute Bewertung signalisiert Vertrauen – sowohl für Besucher als auch für Suchmaschinen.
Klarheit über externe Abhängigkeiten: Der Prozess, einen CSP zu erstellen, zwingt dich, alle externen Ressourcen deiner Website zu inventarisieren. Dabei fallen häufig vergessene Skripte, alte Tracker oder ungenutzte Verbindungen auf.
Compliance-Grundlage: Für Websites mit sensiblen Daten (Shops, Mitgliederbereiche, Kontaktformulare) ist ein CSP-Header ein wichtiger Baustein für DSGVO-Konformität und technische Datenschutzanforderungen.
Was du vor dem Einbinden unbedingt beachten solltest
Ein CSP-Header kann Dinge auf deiner Website brechen, wenn er zu restriktiv konfiguriert ist. Geh diese Punkte durch, bevor du ihn live schaltest.
Alle externen Quellen inventarisieren: Öffne die Browser-Konsole auf deiner Website und schaue unter „Network", welche Domains tatsächlich aufgerufen werden. Trage alle davon in den Generator ein, bevor du generierst.
Report-Only-Modus zuerst: Nutze zunächst den Header Content-Security-Policy-Report-Only statt Content-Security-Policy. Er blockiert noch nichts, zeigt dir aber in der Konsole alle Verstöße an.
Staging-Umgebung nutzen: Wenn du eine Staging-Version deiner Website hast, teste den Header dort zuerst. So riskierst du keine Probleme auf der Live-Website.
Keine kritischen Zeiten: Implementiere Sicherheitsänderungen nicht während hohem Besucheraufkommen. Morgens früh oder am Wochenende ist ideal – falls etwas korrigiert werden muss, hast du Zeit dazu.
Backup vorher: Auch bei einem Sicherheitsheader gilt: Backup zuerst. Gerade wenn du den Header via .htaccess einbindest, kann ein Tippfehler die Website unzugänglich machen.
So setze ich CSP-Header bei meinen Wartungskunden um
Bei einem Sicherheits-Audit für Kundenseiten ist der CSP-Header einer der letzten Punkte, den ich angehe – nicht weil er unwichtig wäre, sondern weil die Grundlage stimmen muss. Ich folge einem bewährten Ablauf.
Schritt 1 – Alle externen Quellen erfassen
Bevor irgendein Header gesetzt wird, inventarisiere ich alle externen Ressourcen der Website. Ich öffne die Browser-Konsole unter „Network", lade jede relevante Seite und notiere alle Domains, von denen Skripte, Styles, Bilder oder Fonts geladen werden. Bei WordPress-Websites kommen dabei oft 10–20 verschiedene Domains zusammen – Google Analytics, Fonts, CDNs, Zahlungsanbieter, Social-Media-Pixel und mehr. Diese Liste ist die Grundlage für den Generator.
Schritt 2 – CSP Generator konfigurieren
Mit der Quellen-Liste öffne ich den CSP Generator und trage alle Domains in die entsprechenden Direktiven ein. Für jede Direktive wähle ich den restriktivsten Wert, der noch funktioniert. 'unsafe-inline' oder 'unsafe-eval' vermeide ich, wo immer möglich – auch wenn das manchmal bedeutet, dass ich ein Plugin-Entwickler kontaktieren oder eine alternative Lösung finden muss.
Schritt 3 – Report-Only-Modus aktivieren
Den generierten Header setze ich zuerst als Content-Security-Policy-Report-Only. Das ist die sichere Methode: Der Browser protokolliert alle Verstöße in der Konsole, blockiert aber noch nichts. Ich gehe dann alle Seiten der Website durch – Startseite, Kontakt, Shop, Warenkorb, Checkout – und schaue, welche Domains noch fehlen. Nach jeder Anpassung im Generator aktualisiere ich den Header und prüfe erneut.
Schritt 4 – Auf echten CSP-Header umstellen
Erst wenn die Browser-Konsole keine CSP-Verstöße mehr zeigt, wechsle ich vom Report-Only-Header auf den echten Content-Security-Policy-Header. Dieser Schritt dauert meistens nur wenige Sekunden – die Arbeit steckt in den vorherigen Schritten. Wichtig: Ich wähle einen ruhigen Zeitpunkt mit wenig Besucherverkehr.
Schritt 5 – Finaler Test und SecurityHeaders.com
Nach dem Umstellen teste ich die Website nochmals vollständig im Browser, prüfe alle wichtigen Funktionen (Formulare, Warenkorb, eingebettete Karten, Videos) und rufe abschließend SecurityHeaders.com auf. Das Ziel ist mindestens ein A, ideal ein A+. Erst wenn das Testergebnis sauber ist und alles funktioniert, ist der Auftrag für mich abgeschlossen.
Fazit: CSP in 5 Minuten statt in einer Stunde
Einen Content-Security-Policy-Header manuell aufzuschreiben war bisher der Part, den die meisten übersprungen haben. Zu viele Direktiven, zu viel Syntax, zu viele Dinge die brechen können.
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.
Wenn du deine Website gerade absicherst oder einen Security-Audit vorbereitest: Schau dir das Tool an.
Wenn du Fragen zu Security Headers hast oder deinen CSP professionell einrichten lassen möchtest, musst du das nicht alleine lösen. Ich schaue mir deine Situation an, prüfe deine aktuelle WordPress-Installation und helfe beim korrekten Einbinden. Schreib mir einfach über die Kontaktseite auf WP Helping Hand – dann schauen wir gemeinsam, welche Sicherheitsheader für deine Website sinnvoll sind.
Das willst du wissen
Was ist ein Content-Security-Policy-Header?
Ein CSP-Header ist eine HTTP-Antwort-Direktive, die dem Browser mitteilt, von welchen Quellen er Inhalte laden darf. Skripte, Styles, Bilder und andere Ressourcen von nicht erlaubten Quellen werden automatisch geblockt – das schützt vor XSS-Angriffen und Content-Injection.
Ist der CSP Generator kostenlos?
Ja, vollständig. Keine Registrierung, kein Abo, keine versteckten Kosten.
Werden meine Daten gespeichert?
Nein. Das Tool läuft vollständig im Browser. Deine Konfiguration wird nicht an einen Server übertragen.
Meine Website bricht nach dem Einbinden des Headers – was tun?
Öffne die Browser-Konsole (F12 → Console). Dort siehst du, welche Ressourcen geblockt wurden und von welcher Domain sie stammen. Füge diese Domain in der entsprechenden Direktive hinzu, generiere einen neuen Header und aktualisiere die Konfiguration.
Funktioniert CSP auch mit dem WordPress-Admin-Bereich?
Ja, aber mit Vorsicht. Der WordPress-Admin nutzt inline Skripte, die durch einen strengen CSP-Header geblockt werden können. Viele Security-Plugins erlauben es, den Header nur für das Frontend zu setzen und den Admin auszunehmen. Das ist in den meisten Fällen der pragmatischste Ansatz.
Brauche ich für jeden Browser einen eigenen Header?
Nein. Alle modernen Browser unterstützen CSP. Die Syntax ist standardisiert.
Was ist der Unterschied zwischen Content-Security-Policy und Content-Security-Policy-Report-Only?
Der reguläre Content-Security-Policy-Header erzwingt die Regeln sofort – Inhalte aus nicht erlaubten Quellen werden geblockt. Content-Security-Policy-Report-Only beobachtet nur: Verstöße werden gemeldet (z. B. in der Browser-Konsole oder an eine Report-URI), aber nichts wird aktiv geblockt. Das ist ideal zum Testen. Du kannst den Report-Only-Header erst einige Tage laufen lassen, die gemeldeten Verstöße auswerten, den Header entsprechend anpassen – und dann erst auf den echten CSP-Header wechseln. So vermeidest du, dass du versehentlich etwas auf deiner Website kaputtmachst.
Muss ich unsafe-inline erlauben, damit WordPress funktioniert?
Das kommt auf deine Installation an. WordPress-Core selbst und viele Plugins nutzen inline Skripte und inline Styles – ohne unsafe-inline kann das zu Darstellungsfehlern oder nicht funktionierenden Elementen führen. Auf der anderen Seite schwächt unsafe-inline den Schutz vor XSS deutlich ab, weil es genau das erlaubt, was Angreifer einschleusen wollen. Ein guter Mittelweg: unsafe-inline zunächst erlauben, die Website testen, und dann schrittweise prüfen, welche Inline-Skripte sich durch Hashes oder Nonces ersetzen lassen. Für die meisten WordPress-Websites ist unsafe-inline in style-src unproblematisch – in script-src sollte man aber genauer hinschauen.
Wie teste ich, ob mein CSP-Header korrekt gesetzt ist?
Am schnellsten geht das über SecurityHeaders.com – einfach deine Domain eingeben und du siehst sofort, welche Security-Header gesetzt sind und wie sie bewertet werden. Alternativ funktioniert auch der Browser direkt: F12 öffnen, auf den Tab „Network“ wechseln, die Seite neu laden, eine Anfrage anklicken und unter „Response Headers“ nach content-security-policy suchen. Wenn der Header dort steht, ist er aktiv.
Beeinflusst ein CSP-Header die Ladegeschwindigkeit meiner Website?
Nein, nicht nennenswert. Der Header wird einmalig mit der HTTP-Antwort des Servers mitgeliefert und ist nur wenige Bytes groß. Die eigentliche Auswertung passiert im Browser und ist so schnell, dass sie keine messbare Auswirkung auf die Performance hat. Was sich indirekt positiv auswirken kann: Wenn du durch den CSP-Header merkst, dass deine Website Skripte von Drittanbietern lädt, die du gar nicht bewusst eingebunden hast, kannst du diese entfernen – das spart tatsächlich Ladezeit.
