Eine Content Security Policy (CSP) ist ein HTTP-Sicherheits-Header, der dem Browser vorschreibt, welche Ressourcen er auf einer Webseite laden darf. Für WordPress bedeutet das: Skripte, Stile, Schriften und andere Inhalte werden nur noch von ausdrücklich erlaubten Quellen geladen. Das macht Cross-Site-Scripting (XSS) und Code-Injection-Angriffe erheblich schwerer. Die folgenden Abschnitte beantworten die wichtigsten Fragen rund um die praktische Umsetzung einer CSP in WordPress.
Was bewirkt eine Content Security Policy auf einer WordPress-Website?
Eine Content Security Policy teilt dem Browser per HTTP-Header mit, welche Quellen für Skripte, Stylesheets, Bilder, Schriften und andere Ressourcen vertrauenswürdig sind. Inhalte aus nicht gelisteten Quellen blockiert der Browser automatisch, noch bevor sie ausgeführt werden. Damit schließt eine CSP die häufigste Angriffsfläche von WordPress-Websites: eingeschleuste Schadskripte.
Der größte praktische Nutzen liegt im Schutz vor XSS-Angriffen. Gelingt es einem Angreifer, über ein anfälliges Plugin oder Formularfeld fremden JavaScript-Code in die Seite einzuschleusen, verhindert die CSP dessen Ausführung, weil die Quelle nicht in der Positivliste steht. Ohne CSP würde der Browser diesen Code bedenkenlos ausführen, was Datendiebstahl, Session-Hijacking oder die Weiterleitung auf Phishing-Seiten ermöglichen kann.
Darüber hinaus schützt eine CSP vor Clickjacking, wenn der Header frame-ancestors korrekt gesetzt ist, und verhindert das ungewollte Einbinden externer Ressourcen, die Tracking-Skripte oder Malware nachladen. Gerade im Kontext der WordPress-Datenschutz-Anforderungen ist das relevant, weil externe Ressourcen häufig personenbezogene Daten übertragen.
Welche CSP-Direktiven sind für WordPress besonders relevant?
Für WordPress-Websites sind vor allem die Direktiven default-src, script-src, style-src, img-src, font-src und frame-ancestors entscheidend. Diese sechs Direktiven decken die Ressourcentypen ab, die WordPress und seine Plugins am häufigsten laden, und bilden damit das Grundgerüst jeder praxistauglichen CSP.
- default-src ’self‘ legt die Standardregel fest: Nur Ressourcen vom eigenen Server sind erlaubt. Alle anderen Direktiven ohne eigene Regel erben diesen Wert.
- script-src steuert, welche JavaScript-Quellen der Browser ausführen darf. Viele WordPress-Plugins laden Skripte von CDNs oder Drittanbietern, die hier explizit freigegeben werden müssen.
- style-src kontrolliert Stylesheets. Inline-Styles, die WordPress und viele Page-Builder erzeugen, erfordern entweder ‚unsafe-inline‘ oder eine Nonce-basierte Lösung.
- img-src regelt Bilder. Wer externe Bilder, Gravatar oder Tracking-Pixel einsetzt, muss die entsprechenden Domains freigeben.
- font-src ist besonders relevant, wenn Schriften von Google Fonts oder Adobe Fonts geladen werden, obwohl aus Datenschutzgründen lokales Hosting vorzuziehen ist.
- frame-ancestors ’none‘ oder ’self‘ verhindert, dass die Seite in einem iframe eingebettet wird, und schützt so vor Clickjacking.
Für WordPress-Shops mit WooCommerce kommen häufig noch connect-src für API-Aufrufe und form-action für Zahlungsanbieter hinzu. Eine zu enge CSP kann Checkout-Prozesse unterbrechen, weshalb diese Direktiven sorgfältig getestet werden müssen.
Wie wird eine Content Security Policy in WordPress technisch eingebunden?
Eine CSP wird in WordPress am zuverlässigsten als HTTP-Response-Header ausgeliefert, entweder über die Serverkonfiguration (Apache oder Nginx) oder per PHP-Code in der functions.php des Themes. Alternativ übernehmen Sicherheits-Plugins wie Wordfence oder Headers & API Manager diese Aufgabe über eine grafische Oberfläche.
Einbindung über die Serverkonfiguration
Bei Apache wird der Header in der .htaccess-Datei gesetzt. Ein einfacher Eintrag lautet: Header set Content-Security-Policy "default-src 'self'". Nginx nutzt die Direktive add_header Content-Security-Policy "..."; in der Server- oder Location-Konfiguration. Diese Methode ist performant, weil der Header vor der PHP-Verarbeitung gesetzt wird, erfordert aber Zugriff auf die Serverkonfiguration, was bei Shared-Hosting-Paketen nicht immer möglich ist. Wer auf ein professionelles WordPress-Hosting setzt, hat hier meist mehr Spielraum.
Einbindung per PHP in WordPress
Ohne Serverzugriff lässt sich der Header in der functions.php des aktiven Child-Themes über den Hook send_headers und die PHP-Funktion header() setzen. Diese Methode funktioniert zuverlässig, solange WordPress vollständig initialisiert wird, greift aber nicht bei direktem Dateiaufruf oder Caching-Schichten, die den PHP-Output umgehen.
Warum bricht eine CSP in WordPress häufig Design oder Funktionen?
Eine CSP bricht in WordPress häufig Design oder Funktionen, weil WordPress-Core, Plugins und Themes routinemäßig Inline-Skripte, Inline-Styles und Ressourcen von Drittanbieter-Domains einsetzen, die von einer strikten CSP standardmäßig blockiert werden. Das ist kein Fehler der CSP, sondern ein Zeichen, dass die Policy noch nicht auf die konkrete Installation abgestimmt ist.
Typische Problemquellen sind:
- Inline-JavaScript und Inline-CSS aus dem Gutenberg-Editor, WooCommerce oder Page-Buildern wie Elementor, die ohne ‚unsafe-inline‘ oder Nonces blockiert werden.
- Externe CDN-Ressourcen von jQuery, Font Awesome, Google Maps oder Zahlungsanbietern wie Stripe und PayPal, die nicht in der Whitelist stehen.
- Dynamisch erzeugte Skripte, die Plugins zur Laufzeit generieren und deren Quelle sich nicht statisch vorhersagen lässt.
- Admin-Bereich und Block-Editor, die eigene Skript- und Stilquellen mitbringen, die sich von der Frontend-CSP unterscheiden können.
Die Lösung liegt nicht darin, pauschal ‚unsafe-inline‘ oder ‚unsafe-eval‘ zu erlauben, weil das den Schutzeffekt der CSP weitgehend aufhebt. Stattdessen sollten Nonces oder Hashes für legitime Inline-Inhalte verwendet und externe Domains gezielt freigeschaltet werden. Wer ohnehin eine WordPress-Wartung in Anspruch nimmt, kann diesen Schritt professionell begleiten lassen.
Wie testet man eine CSP, bevor sie produktiv geht?
Eine CSP wird vor dem produktiven Einsatz im Report-Only-Modus getestet. Dazu wird der Header Content-Security-Policy-Report-Only anstelle von Content-Security-Policy gesetzt. Der Browser blockiert in diesem Modus keine Ressourcen, sondern protokolliert alle Verstöße gegen die Policy, ohne die Seite zu beschädigen.
Der Testprozess läuft in der Praxis in drei Schritten ab:
- Report-Only-Header aktivieren und eine Report-URI angeben, an die Verstöße gemeldet werden. Dienste wie report-uri.com sammeln diese Berichte übersichtlich.
- Alle relevanten Seiten und Funktionen der Website durchklicken: Startseite, Produktseiten, Kontaktformular, Checkout, Login-Bereich und Admin-Backend. Jede genutzte Funktion muss mindestens einmal aufgerufen werden, damit Verstöße sichtbar werden.
- Verstöße auswerten und die Policy anpassen, bis keine unerwünschten Blockierungen mehr im Report erscheinen. Erst dann wird der Header auf den durchsetzenden Modus umgestellt.
Ergänzend empfiehlt sich ein Blick in die Browser-Entwicklertools (Konsole und Netzwerk-Tab), die CSP-Verstöße in Echtzeit anzeigen. Für komplexe Installationen mit vielen Plugins kann der Testprozess mehrere Iterationen benötigen. Die WordPress-Analyse der eigenen Installation hilft dabei, den Umfang realistisch einzuschätzen.
Reicht eine Content Security Policy als einzige Sicherheitsmaßnahme für WordPress aus?
Nein, eine Content Security Policy allein reicht nicht aus, um eine WordPress-Website umfassend abzusichern. Eine CSP ist eine wichtige Verteidigungsschicht gegen XSS und Code-Injection, schützt aber nicht vor Brute-Force-Angriffen, veralteten Plugins mit bekannten Sicherheitslücken, schwachen Passwörtern, kompromittierten Themes oder direkten Angriffen auf die Datenbank.
Zu einem vollständigen Sicherheitskonzept für WordPress gehören mindestens:
- Regelmäßige Updates von WordPress-Core, Plugins und Themes, weil die meisten erfolgreichen Angriffe bekannte, ungepatchte Schwachstellen ausnutzen.
- Starke Passwörter und Zwei-Faktor-Authentifizierung für alle Backend-Nutzer, insbesondere Administratoren.
- Eine Web Application Firewall (WAF), die bösartigen Traffic bereits vor dem Erreichen der Anwendung filtert.
- Tägliche Backups, die extern gespeichert werden, damit im Angriffsfall eine saubere Version wiederhergestellt werden kann.
- HTTPS mit korrekt konfiguriertem TLS sowie ergänzende Security-Header wie X-Frame-Options, X-Content-Type-Options und Strict-Transport-Security.
- Monitoring auf Malware und verdächtige Dateiänderungen, das Angriffe frühzeitig erkennt, bevor sie Schaden anrichten.
Die CSP ist damit ein wertvoller Baustein, aber kein Ersatz für ein mehrschichtiges Sicherheitskonzept. Wer die Malware-Bereinigung nach einem Angriff vermeiden möchte, investiert besser präventiv in alle Schichten gleichzeitig.
So hilft WP-Profi beim Absichern Ihrer WordPress-Website
Eine korrekt konfigurierte Content Security Policy ist technisch anspruchsvoll, besonders wenn Plugins, WooCommerce und externe Dienste im Spiel sind. Wir bei WP-Profi übernehmen die vollständige Sicherheitskonfiguration Ihrer WordPress-Website, damit Sie sich auf Ihr Kerngeschäft konzentrieren können.
Konkret unterstützen wir Sie mit:
- Analyse Ihrer bestehenden Installation auf Sicherheitslücken, veraltete Komponenten und fehlende Security-Header
- Einrichtung und Feinabstimmung der CSP im Report-Only-Modus mit iterativer Auswertung und anschließender produktiver Aktivierung ohne Funktionsverlust
- Konfiguration aller relevanten Security-Header abgestimmt auf Ihre konkrete WordPress-Installation
- Laufendem Schutz durch unsere Wartungspakete mit Firewall, täglichen Backups, wöchentlichen Updates und Malware-Monitoring ab 14 Euro monatlich
- Notfallsupport an Wochenenden und Feiertagen sowie professioneller Hack-Bereinigung innerhalb von 24 Stunden, falls doch etwas passiert
Alle Daten werden DSGVO-konform ausschließlich auf Servern in Deutschland verarbeitet. Sprechen Sie uns an und lassen Sie uns gemeinsam eine Sicherheitsstrategie entwickeln, die zu Ihrer Website und Ihrem Unternehmen passt.
Die auf dieser Website bereitgestellten Informationen zu Datenschutz und DSGVO dienen ausschließlich allgemeinen Informationszwecken und stellen keine Rechtsberatung dar; für verbindliche rechtliche Einschätzungen empfehlen wir die Konsultation eines qualifizierten Rechtsanwalts.
Ähnliche Artikel
- Was sind die konkreten Vorteile einer professionell gestalteten WordPress Website?
- Was unterscheidet einen erfahrenen WordPress Experten von einem Anfänger?
- Was ist bei der Informationsarchitektur und Struktur einer WordPress Website zu beachten?
- Was ist ein WordPress Hook und wie funktioniert er in der Entwicklung?
- Wie erstellt man ein individuelles WordPress Child-Theme für ein maßgeschneidertes Design?
Dieser Inhalt wurde mithilfe von KI erstellt und kann Fehler enthalten.


