Setzen Sie zuerst HSTS, X-Content-Type-Options und Referrer-Policy auf Serverebene, und zwar erst nachdem HTTPS sauber läuft. Die Content-Security-Policy kommt danach, zunächst im Report-Only-Modus, damit Sie Fehler sehen, bevor sie live blockieren. .htaccess, vHost oder nginx-Konfiguration sind die robustere Ebene gegenüber Plugins oder functions.php. Ein Preload-Eintrag für HSTS folgt erst ganz am Ende, wenn wirklich alles geprüft ist.
Kurz gesagt:
- Für eine sichere Konfiguration sollten HSTS, X-Content-Type-Options und Referrer-Policy erst nach stabilen HTTPS-Verbindungen auf Serverebene gesetzt werden.
- Die Content-Security-Policy ist komplex, aber der wichtigste Schutz gegen Cross-Site-Scripting, sollte daher im Report-Only-Modus getestet werden, bevor sie live geschaltet wird.
- Serverseitige Header setzen ist zuverlässiger als Plugins oder functions.php, wobei bei Apache und nginx spezielle Hinweise für die korrekte Implementierung zu beachten sind.
- Eine Preload-Anfrage für HSTS sollte erst nach vollständiger Prüfung und validation aller Subdomains und Zertifikate erfolgen, da sie nur schwer rückgängig gemacht werden kann.
- Regelmäßige Tests der Header-Antkommen mit Tools wie securityheaders.com oder Mozilla Observatory sind notwendig, um tatsächliche Sicherheit auf der Website zu gewährleisten.
Inhaltsverzeichnis
- Was sind Sicherheitsheader in WordPress und wozu dienen sie?
- Header in WordPress setzen: Server, .htaccess, functions.php oder Plugin?
- CSP einführen, ohne die Website zu brechen
- HSTS sicher einführen und die Preload-Frage klären
- Wie prüfen Sie, ob Ihre Header wirklich ankommen?
- Konfigurationsbeispiele für Apache, nginx und PHP
- Wann lohnt sich professionelle Unterstützung beim Security-Rollout?
- Werbeeinfach übernimmt Ihren Security-Rollout für WordPress
- Quellen
- FAQ
Was sind Sicherheitsheader in WordPress und wozu dienen sie?
HTTP-Sicherheitsheader sind Anweisungen, die Ihr Server bei jeder Antwort an den Browser mitschickt. Sie sagen dem Browser, wie er mit Inhalten umgehen soll und erschweren damit Angriffe wie Cross-Site-Scripting, Clickjacking und MIME-Snarfing erheblich. Für eine WordPress-Seite mit Kontaktformularen, Login-Bereich oder WooCommerce-Checkout ist das keine Kür, sondern eine Grundabsicherung, die neben Passwortschutz und Updates dazugehört.
Die folgenden Header bilden das Fundament. web.dev empfiehlt genau diese Kombination als Basisausstattung für Websites mit sensiblen Daten:
- Content-Security-Policy (CSP): Legt fest, von welchen Quellen Skripte, Styles und Bilder geladen werden dürfen. Der wirksamste Schutz gegen Cross-Site-Scripting, aber auch der komplexeste einzuführen. Beispiel-Direktive:
default-src 'self'; script-src 'self' 'nonce-xyz123'. - HTTP Strict-Transport-Security (HSTS): Zwingt Browser, Ihre Domain nur noch über HTTPS aufzurufen, selbst wenn jemand versehentlich
http://eingibt. Beispiel:Strict-Transport-Security: max-age=eine angemessene Zeitspanne, inklusive Subdomains. - X-Content-Type-Options: Verhindert, dass der Browser Dateitypen errät und dadurch schädlichen Code als harmlos einstuft. Nur eine Direktive existiert:
X-Content-Type-Options: nosniff. - Referrer-Policy: Steuert, wie viel von Ihrer URL an externe Ziele weitergegeben wird, wenn Nutzer einen Link anklicken. Empfehlenswert:
Referrer-Policy: strict-origin-when-cross-origin. - Permissions-Policy (früher Feature-Policy): Schaltet Browser-Funktionen wie Kamera, Mikrofon oder Standortabfrage gezielt ab, wenn Ihre Seite sie nicht braucht. Beispiel:
Permissions-Policy: camera=(), microphone=(). - Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, Cross-Origin-Resource-Policy (COOP/COEP/CORP): Isolieren Ihre Seite von fremden Browser-Kontexten und verhindern bestimmte Seitenkanalangriffe.
- X-Frame-Options / frame-ancestors: Verhindert, dass Ihre Seite in einem fremden iframe eingebettet und für Klickbetrug missbraucht wird.
frame-ancestors 'self'in der CSP übernimmt diese Aufgabe inzwischen moderner als der alteX-Frame-Options-Header.
X-Frame-Options gilt als veraltet, funktioniert aber noch in älteren Browsern. Setzen Sie deshalb beides parallel: frame-ancestors in der CSP für moderne Browser, X-Frame-Options: SAMEORIGIN als Rückfallebene.
Header in WordPress setzen: Server, .htaccess, functions.php oder Plugin?
Vier Wege führen zum Ziel, aber sie unterscheiden sich stark in Zuverlässigkeit und Reichweite. Die Server-Level-Konfiguration über vHost-Datei oder Angina-Serverblock deckt jede Antwort ab, die Ihr Server ausliefert, also HTML-Seiten genauso wie Bilder, CSS-Dateien und Redirects. PHP- oder Plugin-Lösungen erreichen dagegen nur PHP-gerenderte Antworten und lassen statische Assets oft ungeschützt.
Wenn Sie Root- oder vHost-Zugriff haben, ist das die erste Wahl. .htaccess ist die zweitbeste Option, sinnvoll, wenn Ihr Hoster keinen vHost-Zugang gewährt. functions.php ist die dritte Option, brauchbar als Übergangslösung, aber mit Lücken. Plugins sind der letzte Ausweg, wenn keine der anderen Optionen offensteht.
Schrittweises Vorgehen für die Serverebene
- Prüfen Sie, ob
mod_headersbei Apache aktiv ist. Ohne dieses Modul greift keinHeaderBefehl. Ein kurzer Test mitapachectl -M | grep headerszeigt es Ihnen. - Nutzen Sie immer
Header always setstatt nurHeader set. Ohne das Schlüsselwort „always“ fehlen Header bei Fehlerseiten (404, 500) und bei Redirects, genau den Antworten, die Angreifer gern zuerst testen. - Prüfen Sie
AllowOverridein der vHost-Konfiguration. Steht dortAllowOverride None, greifen Ihre .htaccess-Regeln überhaupt nicht, egal wie korrekt sie geschrieben sind. Das ist einer der häufigsten Gründe, warum Header „einfach nicht ankommen“. - Platzieren Sie eigene Regeln außerhalb des WordPress-Blocks. Alles zwischen
# BEGIN WordPressund# END WordPresswird bei jedem Permalink-Speichern von WordPress überschrieben. Ihre Header-Regeln gehören davor oder danach. - Testen Sie nach jeder Änderung sofort. Ein einziger Tippfehler in der .htaccess kann die gesamte Seite mit einem 500er-Fehler lahmlegen.
Bei nginx übernimmt add_header ... always dieselbe Funktion wie das Apache-Pendant. Wichtig ist hier ein Detail, das viele übersehen: Ein add_header innerhalb eines location-Blocks kann sämtliche Header aus dem übergeordneten server-Block unterlaufen, weil nginx die Vererbung stoppt, sobald in einem Block überhaupt ein add_header auftaucht. Die Lösung: entweder alle Header-Anweisungen in jedem location-Block wiederholen oder eine gemeinsame Include-Datei einbinden.
functions.php mit dem send_headers-Hook ist praktikabel, wenn kein Serverzugriff besteht:
add_action('send_headers', function() {
header('X-Content-Type-Options: nosniff');
header('Referrer-Policy: strict-origin-when-cross-origin');
});
Diese Methode greift nur bei Anfragen, die tatsächlich durch PHP laufen. Bilder, CSS- und JS-Dateien, die direkt vom Webserver ausgeliefert werden, bekommen diese Header nicht. Das ist die typische Lücke, die Tester dann bei einem Audit als fehlend markieren.
Plugins wie das kostenlose Security Header bieten eine Oberfläche, über die auch technisch weniger versierte Betreiber Header setzen und den Report-Only-Modus für CSP aktivieren können. Nützlich, wenn kein Serverzugang existiert, aber mit eigenen Risiken: In Multisite-Umgebungen kann ein Plugin Header pro Subseite unterschiedlich setzen und für Verwirrung sorgen, und wenn parallel schon serverseitige Regeln existieren, entstehen doppelte Header.
Profi-Tipp: Setzen Sie einen Header niemals doppelt. Ein Server-Header plus ein Plugin-Header für dieselbe Direktive führt bei CSP zum sogenannten Intersection-Effekt: Der Browser wendet nur die strengste gemeinsame Schnittmenge beider Regeln an, was oft Skripte blockiert, die eigentlich erlaubt sein sollten.
Die operative Reihenfolge beim Rollout bleibt immer gleich: erst das SSL-Zertifikat einrichten, dann den HTTPS-Redirect erzwingen, danach HSTS mit niedrigem max-age-Wert aktivieren, und erst zum Schluss dauerhaftes Monitoring aufsetzen. Wer diese Reihenfolge umdreht und HSTS vor einem stabilen HTTPS-Redirect setzt, riskiert, dass Besucher bei einem Zertifikatsfehler komplett ausgesperrt werden.
CSP einführen, ohne die Website zu brechen
Eine Content-Security-Policy scharf zu schalten, ohne vorher zu testen, ist der sicherste Weg, den WooCommerce-Checkout oder eingebettete Google-Maps-Karten lahmzulegen. Der richtige Einstieg heißt deshalb Content-Security-Policy-Report-Only statt der scharfen Variante. Der Browser meldet dann jede Verletzung, blockiert aber nichts.
- Konfigurieren Sie
report-tooder das älterereport-uri, damit Verstöße an einen Endpunkt gemeldet werden, den Sie auswerten können. - Sammeln Sie mindestens ein bis zwei Wochen Daten, idealerweise über einen kompletten Bestellzyklus im Shop hinweg.
- Prüfen Sie jede gemeldete Domain: Zahlungsanbieter, Tracking-Skripte, eingebettete Videos, Google Fonts. Jede davon braucht einen Eintrag in Ihrer
script-srcoderframe-src. - Testen Sie den Checkout-Prozess komplett auf einer Staging-Umgebung, bevor Sie die Policy live erzwingen.
MDN weist ausdrücklich darauf hin, dass zwei gleichzeitig aktive CSP-Header, etwa einer vom Server und einer von einem Plugin, sich nicht ergänzen, sondern überschneiden. Der Browser wendet dann nur die Schnittmenge beider Regelsätze an, was erlaubte Skripte blockiert, ohne dass eine Fehlermeldung im Frontend auf die Ursache hinweist.
Für dynamisch generierte Inline-Skripte, etwa von manchen Page-Buildern, sind Nonces die sauberere Lösung gegenüber pauschalem unsafe-inline. Ein Nonce ist ein einmaliger Zufallswert, der bei jeder Anfrage neu generiert wird und im Skript-Tag sowie im Header übereinstimmen muss. Genau hier liegt eine Falle für Caching-Plugins: Wird eine Seite mit eingebettetem Nonce als statische Datei gecacht und an mehrere Besucher ausgeliefert, funktioniert der Nonce nicht mehr korrekt. Antworten mit Nonce brauchen deshalb Cache-Control: private, damit kein gemeinsamer Cache oder CDN sie weiterverteilt.
HSTS sicher einführen und die Preload-Frage klären
HSTS ist mächtig, aber auch das Element mit dem größten Nachholeffekt bei einem Fehler. Ein zu aggressiv gesetzter max-age sperrt Besucher tagelang aus, falls mit dem Zertifikat etwas schiefgeht. Deshalb gilt eine klare Reihenfolge:
- Starten Sie mit einem niedrigen
max-age, etwa einige Stunden oder wenige Tage, während Sie beobachten, ob HTTPS auf allen Bereichen stabil läuft. - Erhöhen Sie den Wert schrittweise, erst auf Wochen, dann auf einen langfristigen Zeitraum.
- Aktivieren Sie
includeSubDomainserst, wenn wirklich jede Subdomain, auch Mail- oder Testserver, per HTTPS erreichbar ist. Eine einzige HTTP-only-Subdomain wird sonst komplett unerreichbar. - Erwägen Sie
preloaderst zum Schluss, und nur nach vollständiger Prüfung.
Die Aufnahme in die Preload-Liste von Browsern ist an strikte Bedingungen geknüpft: max-age von mindestens einem Jahr, includeSubDomains und preload müssen gesetzt sein, und gültige HTTPS-Zertifikate müssen für sämtliche Subdomains vorliegen. Das Entscheidende dabei: Eine Aufnahme in diese Liste ist praktisch dauerhaft und lässt sich nur schwer und langsam rückgängig machen, weil die Liste fest in Browsern einkompiliert wird. Vor einem Preload-Antrag gehört deshalb jede Subdomain, jeder Redirect und jedes Zertifikat auf den Prüfstand.
Wie prüfen Sie, ob Ihre Header wirklich ankommen?
Ein gesetzter Header im Code bedeutet nicht automatisch, dass er beim Besucher ankommt. CDN, Cache-Plugin oder eine vergessene location-Regel bei nginx können Header unterwegs verschlucken.
- securityheaders.com liefert eine schnelle Bewertung mit Note von A bis F und zeigt fehlende Header sofort an.
- Mozilla Observatory geht tiefer und bewertet zusätzlich CSP-Qualität und TLS-Konfiguration.
- WebPageTest zeigt Header pro einzelner Ressource, nützlich um zu sehen, ob auch Bilder und Skripte die Header tragen.
- Der Netzwerk-Tab in den Browser-Entwicklertools zeigt in Echtzeit, was tatsächlich beim Client ankommt, inklusive Redirects und Fehlerseiten.
Prüfen Sie nicht nur die Startseite. Testen Sie auch eine 404-Fehlerseite, einen HTTP-zu-HTTPS-Redirect und, falls vorhanden, eine über ein CDN ausgelieferte statische Datei. Genau an diesen Stellen fehlen Header am häufigsten, weil Entwickler nur die normale HTML-Antwort im Blick hatten. Ein guter Score bei securityheaders.com oder Mozilla Observatory ist ein nützliches Signal, ersetzt aber keine umfassende Anwendungssicherheit, etwa saubere Eingabevalidierung oder aktuelle Plugin-Versionen.
Konfigurationsbeispiele für Apache, nginx und PHP
Für Apache gehören folgende Zeilen in die vHost-Konfiguration oder, falls kein Zugriff darauf besteht, in die .htaccess außerhalb des WordPress-Blocks:
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Strict-Transport-Security "max-age=eine angemessene Zeitspanne; includeSubDomains"
Header always set Content-Security-Policy-Report-Only "default-src 'self'; report-uri /csp-report"
</IfModule>
Bei nginx sieht die entsprechende Konfiguration im Serverblock so aus:
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Strict-Transport-Security "max-age=eine angemessene Zeitspanne; includeSubDomains" always;
Denken Sie daran, diese Zeilen in jedem location-Block zu wiederholen, der eigene add_header-Anweisungen enthält, sonst gehen die Regeln aus dem Serverblock verloren.
Für den PHP-Weg über functions.php, wenn kein Server- oder .htaccess-Zugriff besteht:
add_action('send_headers', function() {
header('X-Content-Type-Options: nosniff');
header('Referrer-Policy: strict-origin-when-cross-origin');
});
- Spielen Sie jede Änderung zuerst auf einer Staging-Kopie ein, nie direkt auf der Live-Seite.
- Testen Sie nach jeder Zeile mit dem Browser-Netzwerk-Tab, ob der Header ankommt.
- Prüfen Sie explizit eine Fehlerseite und einen Redirect, nicht nur die Startseite.
- Erst wenn alle drei Ebenen (HTML, Assets, Redirects) den Header zeigen, gilt der Rollout als abgeschlossen.
Bei WordPress-Multisite-Installationen gilt dieselbe Logik pro Domain oder Subdomain. Nutzen Sie Domain-Mapping, muss die Server-Konfiguration jede zugeordnete Domain einzeln abdecken, denn eine zentrale .htaccess im Hauptverzeichnis reicht bei eigenständigen Domains oft nicht aus. Zur Performance: Sicherheitsheader selbst kosten praktisch keine Ladezeit, sie sind wenige Bytes pro Antwort. Google wertet HTTPS und eine solide Sicherheitskonfiguration indirekt positiv, doch Header allein verbessern kein Ranking, sie verhindern nur, dass ein Sicherheitsvorfall Ihre Sichtbarkeit zerstört. Bei älteren Browsern, die COOP oder Permissions-Policy nicht kennen, ignorieren diese den Header einfach, ohne Fehler zu werfen, ein Kompatibilitätsrisiko besteht hier praktisch nicht.
Wann lohnt sich professionelle Unterstützung beim Security-Rollout?
Nicht jeder Website-Betreiber hat Root-Zugriff auf den Server oder Zeit, wochenlang Report-Only-Daten auszuwerten. Wenn Ihr Hosting-Paket keinen vHost-Zugang erlaubt, Sie einen komplexen WooCommerce-Checkout mit mehreren Zahlungsanbietern betreiben oder über eine Multisite-Installation mit mehreren Domains nachdenken, wird aus einer Nachmittagsaufgabe schnell ein mehrwöchiges Projekt. Auch die Preload-Entscheidung, die kaum rückgängig zu machen ist, verdient einen zweiten Blick von jemandem, der das schon oft gemacht hat.
Werbeeinfach übernimmt Ihren Security-Rollout für WordPress
Werbeeinfach ist die Alternative zum Trial-and-Error mit .htaccess-Dateien und Copy-Paste-Snippets aus Foren: Statt Sie durch Report-Only-Auswertungen, Nonce-Konfiguration und die Preload-Entscheidung allein zu schicken, übernehmen wir den kompletten Rollout auf Serverebene, sauber getestet, bevor irgendetwas live geht.
Als WordPress-Agentur betreuen wir Unternehmen und Onlineshops bundesweit, von der Neuentwicklung bis zur laufenden WordPress Wartung. Unsere Sicherheitspakete für Websites decken genau die Themen ab, die in diesem Artikel eine Rolle spielen: HTTPS-Migration, CSP- und HSTS-Rollout, Multisite-Konfiguration und regelmäßige Audits. Wenn Sie planen, Ihre HTTPS-Umstellung sauber mit Header-Konfiguration zu verbinden, oder Ihre Seite zunächst durch ein Sicherheitsaudit prüfen lassen wollen, ist das ein guter Ausgangspunkt für ein Gespräch. Kontaktieren Sie uns, schildern Sie Ihre Serverumgebung, und wir sagen Ihnen ehrlich, ob ein Rollout in Tagen oder Wochen realistisch ist.
Quellen
Für tieferes Nachschlagen eignen sich diese Quellen: MDN für exakte CSP-Direktiven, web.dev für eine kompakte Übersicht empfohlener Header, hstspreload.org für den Preload-Check Ihrer Domain sowie Mozilla Observatory und securityheaders.com für regelmäßige Audits.
FAQ
Welche Sicherheitsplugins gibt es für WordPress?
Es gibt spezialisierte Header-Plugins wie Security Header, die eine Oberfläche zum Setzen von HSTS, CSP und Co. bieten, inklusive Report-Only-Modus. Für WooCommerce-Shops lohnt zusätzlich ein Blick auf spezialisierte Security-Plugin-Übersichten, da Shop-Umgebungen zusätzliche Angriffsflächen wie Zahlungsformulare mitbringen.
Wie kann ich meine WordPress-Website sicher machen?
Eine sichere Website kombiniert mehrere Ebenen: aktuelle WordPress-Kern-, Theme- und Plugin-Versionen, starke Zugangsdaten, regelmäßige Backups und eben die hier beschriebenen Sicherheitsheader auf Serverebene. Es werden auch Sicherheitspakete angeboten, die diese Bausteine zusammenführen.
Wie kann ich den Header in WordPress gestalten?
Meinen Sie damit den sichtbaren Seitenkopf im Theme, gehört das in den Theme-Customizer oder Page-Builder Ihrer Wahl, nicht in die HTTP-Header-Konfiguration. Geht es um HTTP-Sicherheitsheader wie CSP oder HSTS, setzen Sie diese über die vHost-Datei, die .htaccess oder ersatzweise über functions.php mit dem send_headers-Hook.
Wie kann ich eine WordPress-Seite auf Sicherheit überprüfen?
Prüfen Sie zunächst mit securityheaders.com oder Mozilla Observatory, welche Header überhaupt ankommen, und testen Sie dabei nicht nur die Startseite, sondern auch Fehlerseiten und Redirects. Für eine tiefere Prüfung inklusive Plugin-Versionen und Dateiberechtigungen eignet sich ein vollständiges WordPress-Sicherheitsaudit.
Was kostet die Einrichtung von Sicherheitsheadern durch Werbeeinfach?
Die Kosten hängen von Ihrer Serverumgebung und dem Umfang des Rollouts ab, etwa ob CSP mit vielen Drittanbietern konfiguriert werden muss. Aktuelle Preise für Wartung und Sicherheitspakete finden Sie direkt auf der Wartungsseite.
