Du hast ein SSL-Zertifikat. Du machst regelmäßige Updates. Du nutzt ein Sicherheits-Plugin. Alles gut, oder?
Nicht ganz. Es gibt eine Kategorie von Sicherheitsmaßnahmen, die WordPress von sich aus nicht einrichtet – und die von den meisten Sicherheits-Plugins entweder gar nicht oder falsch gehandhabt wird: HTTP Security Headers.
Das Problem dabei ist nicht, dass sie schwer einzurichten wären. Das Problem ist, dass die meisten WordPress-Betreiber nie erfahren, dass sie fehlen. Die Website läuft, Google indexiert sie, niemand beschwert sich – und trotzdem fehlt ein wichtiger Schutzlayer, der Clickjacking, MIME-Sniffing und bestimmte XSS-Angriffe verhindern würde.
In diesem Beitrag erkläre ich, was Security Headers sind, welche 8 davon für WordPress-Websites relevant sind, und wie du in etwa fünf Minuten herausfindest, wie deine Website abschneidet.
Was sind HTTP Security Headers?
Wenn ein Browser deine Website aufruft, schickt der Server nicht nur HTML zurück – er schickt auch eine Reihe von Antwort-Headern. Die meisten davon sind technischer Natur (Inhaltstyp, Caching, Weiterleitungen). Security Headers sind eine Teilmenge dieser Header, die dem Browser mitteilen, wie er die Website behandeln soll.
Konkret heißt das: du kannst dem Browser sagen, ob deine Seite in einem iframe eingebettet werden darf (relevant für Clickjacking-Schutz), ob er den Dateityp von Ressourcen selbst “erraten” soll oder ob du ihm das verbietest, und welche externen Quellen legitim Skripte auf deiner Seite ausführen dürfen.
Der Browser setzt diese Regeln durch – automatisch, ohne dass dein WordPress-Code irgendwas davon mitbekommt.
Das ist der Vorteil: Wenn ein Angreifer es schafft, bösartigen Code in ein Plugin einzuschleusen, kann ein gut gesetzter Content-Security-Policy-Header trotzdem verhindern, dass dieser Code etwas anrichten kann, weil der Browser die Ausführung blockiert.
Das Plugin-Problem
Jetzt kommt der Grund, warum das Thema in der WordPress-Welt so oft unter den Tisch fällt.
Es gibt Plugins, die Security Headers setzen. Das klingt nach einer einfachen Lösung. Aber die Realität ist komplizierter:
Plugins setzen Header per PHP. Das passiert spät im Request – nach WordPress-Core, nach Themes, nach anderen Plugins. Wenn irgendwo in dieser Kette jemand die Header überschreibt, sind deine Security Headers weg. Du siehst das nicht im Admin-Dashboard.
Caching-Plugins können das Problem verstärken. Wenn Seiten gecacht werden, bevor dein Security-Header-Plugin läuft, werden möglicherweise Seiten ohne Header ausgeliefert.
CDN und Proxy-Layer. Viele WordPress-Websites laufen hinter Cloudflare oder einem nginx-Reverse-Proxy. Beide können Header modifizieren oder entfernen. Das Plugin weiß davon nichts.
Das Ergebnis: Dein Plugin zeigt dir grüne Häkchen. Aber was der Browser tatsächlich empfängt, kann vollständig anders aussehen. Das lässt sich nur von außen prüfen – indem du die echten Response-Header abrufst, die beim Besucher ankommen.
Die 8 Security Headers, die für WordPress wichtig sind
1. Content-Security-Policy (CSP)
Der mächtigste und komplexeste Header. Er definiert, welche Ressourcen der Browser laden darf – und von wo. Ein striktes CSP verhindert, dass ein Angreifer auch dann JS ausführen kann, wenn er Code in deine Seite einschleusen konnte.
Der Haken: CSP ist anspruchsvoll zu konfigurieren, weil viele WordPress-Themes und -Plugins externe Ressourcen einbinden. Ein zu striktes CSP bricht die Website; ein zu lockeres nützt wenig. Nutze unseren CSP Generator, um eine saubere Policy aufzubauen.
Beispiel-Wert: Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-xyz'; img-src 'self' data:
2. Strict-Transport-Security (HSTS)
Dieser Header sagt dem Browser: Ruf diese Website nie über HTTP auf – immer HTTPS. Das klingt trivial, wenn du bereits eine SSL-Umleitung hast. Aber ohne HSTS ist der erste Request noch angreifbar (Man-in-the-Middle). Mit HSTS merkt sich der Browser nach dem ersten Besuch, dass er immer HTTPS verwenden soll.
Wichtig: max-age sollte mindestens 31536000 Sekunden (1 Jahr) betragen, und includeSubDomains sollte gesetzt sein, wenn du Subdomains nutzt.
Beispiel-Wert: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
3. X-Frame-Options
Dieser Header verhindert, dass deine Website in einem <iframe> auf einer fremden Website eingebettet wird. Das klassische Angriffsszenario: Clickjacking. Der Angreifer blendet deine Website unsichtbar über einer anderen Seite ein, und der Nutzer klickt, ohne es zu wissen, auf Buttons deiner Website.
Für die meisten WordPress-Websites ist SAMEORIGIN der richtige Wert – also nur eigene Seiten dürfen einbetten.
Beispiel-Wert: X-Frame-Options: SAMEORIGIN
4. X-Content-Type-Options
Browser versuchen manchmal, den Dateityp einer Ressource selbst zu erraten, wenn der Server keinen klaren Content-Type angibt. Das nennt sich MIME-Sniffing. Angreifer können das ausnutzen, indem sie eine Datei so hochladen, dass der Browser sie als JavaScript interpretiert, obwohl sie offiziell als Bild deklariert ist.
nosniff deaktiviert dieses Verhalten.
Beispiel-Wert: X-Content-Type-Options: nosniff
5. Referrer-Policy
Wenn jemand auf deiner Website auf einen externen Link klickt, schickt der Browser standardmäßig die vollständige URL deiner Seite als “Referrer” mit. Das kann sensible Informationen preisgeben (z. B. interne Seitennamen, Parameter, Login-Pfade).
strict-origin-when-cross-origin ist ein guter Kompromiss: Der Referrer wird beim Wechsel auf eine andere Domain auf den reinen Hostnamen reduziert.
Beispiel-Wert: Referrer-Policy: strict-origin-when-cross-origin
6. Permissions-Policy
Früher “Feature-Policy” genannt. Damit kannst du festlegen, welche Browser-Features deine Website nutzen darf – und welche nicht. Kamera, Mikrofon, Standort, Accelerometer. Wenn deine Website keinen dieser Zugriffe braucht, solltest du sie explizit verbieten.
Beispiel-Wert: Permissions-Policy: camera=(), microphone=(), geolocation=()
7. X-XSS-Protection (veraltet)
Dieser Header existiert noch, wird aber nicht mehr empfohlen. Er war für alte Browser gedacht, die keinen eigenen XSS-Filter hatten. Moderne Browser ignorieren ihn oder haben ihn ganz entfernt. Wenn du ihn noch irgendwo gesetzt hast: ersetze ihn durch eine saubere CSP.
8. Cross-Origin-Opener-Policy (COOP)
Der neueste der acht. Er isoliert deinen Browser-Tab von anderen Tabs und verhindert, dass externe Seiten, die du öffnest, über JavaScript-Referenzen auf dein Tab zugreifen können. Relevant für Websites mit Login oder sensibler Funktionalität.
Beispiel-Wert: Cross-Origin-Opener-Policy: same-origin
Der Fehler, den fast alle machen
Wer das Thema recherchiert, findet schnell .htaccess-Snippets wie diesen:
<IfModule mod_headers.c>
Header set X-Frame-Options "SAMEORIGIN"
Header set X-Content-Type-Options "nosniff"
Header set Strict-Transport-Security "max-age=31536000"
</IfModule>Einfügen, fertig, grüne Häkchen bei securityheaders.com – so lautet die gängige Anleitung.
Das Problem: Nach dem Einbauen prüft niemand mehr, ob die Header beim Besucher tatsächlich ankommen. Und das tun sie nicht immer. Ein paar typische Szenarien, wo Header still und leise verschwinden:
- Cloudflare überschreibt oder entfernt bestimmte Header je nach Plan und Konfiguration
- WP Rocket oder W3 Total Cache liefern gecachte Seiten aus, bevor PHP-basierte Header gesetzt werden können
- nginx als Reverse-Proxy vor Apache hat eigene Header-Konfigurationen, die Priorität haben
- Managed WordPress Hosting (Kinsta, WP Engine, Flywheel) konfiguriert Header auf Server-Ebene – manchmal richtig, manchmal gar nicht
Das lässt sich nicht durch Blick ins Plugin-Dashboard oder die .htaccess klären. Du musst von außen schauen.
Wie du deine Security Headers prüfst
Dafür haben wir den HTTP Security Headers Checker gebaut.
URL eingeben, Prüfung starten. Das Tool fetcht serverseitig die echten Response-Header deiner Website – also das, was der Browser eines echten Besuchers tatsächlich empfängt. Dann analysiert es alle 8 Header, berechnet einen Security Score von 0–100 und zeigt dir konkret, was fehlt oder schwach konfiguriert ist.
Für jeden problematischen Header gibt es direkt den passenden Code: als .htaccess-Block, als nginx-Direktive oder als PHP-Snippet für die functions.php. Kopieren, einbauen, nochmal prüfen.
Das Tool ist kostenlos, ohne Registrierung, und speichert keine Inhalte deiner Website – nur die Response-Header werden analysiert.
Security Headers in WordPress einrichten: Drei Wege
Wenn der Check zeigt, dass Header fehlen, hast du im Wesentlichen drei Optionen:
Weg 1: .htaccess (empfohlen für Apache-Hosting)
Füge den Header-Block in deine .htaccess im WordPress-Stammverzeichnis ein, vor dem WordPress-Block. Funktioniert auf den meisten Shared-Hosting-Paketen und ist unabhängig von Plugins.
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set Cross-Origin-Opener-Policy "same-origin"
</IfModule>Beachte always statt set – das stellt sicher, dass die Header auch bei 3xx- und 4xx-Antworten gesetzt werden.
Weg 2: functions.php (oder Must-Use-Plugin)
Wenn du keinen Zugriff auf .htaccess hast oder nginx nutzt, kannst du Header per PHP setzen:
add_action( 'send_headers', function() {
header( 'Strict-Transport-Security: max-age=31536000; includeSubDomains; preload' );
header( 'X-Frame-Options: SAMEORIGIN' );
header( 'X-Content-Type-Options: nosniff' );
header( 'Referrer-Policy: strict-origin-when-cross-origin' );
header( 'Permissions-Policy: camera=(), microphone=(), geolocation=()' );
header( 'Cross-Origin-Opener-Policy: same-origin' );
} );Setze das besser in ein Must-Use-Plugin (/wp-content/mu-plugins/) statt in die functions.php des Themes – dann bleibt es bei Theme-Wechseln und Theme-Updates erhalten.
Weg 3: Nginx-Konfiguration
Wenn du Zugriff auf die nginx-Serverkonfiguration hast (VPS, eigener Server), sind Header auf Server-Ebene die sicherste Option – sie werden unabhängig von WordPress gesetzt und können von keinem Plugin überschrieben werden.
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Cross-Origin-Opener-Policy "same-origin" always;Nach dem Einrichten: Nochmal prüfen
Das klingt trivial, wird aber häufig vergessen: Nach jeder Änderung nochmal mit dem HTTP Security Headers Checker prüfen. Nicht weil der Code falsch ist, sondern weil Caching, CDN-Layer oder Hosting-Konfigurationen dazwischenfunken können.
Auch nach größeren WordPress-Updates, Plugin-Updates oder Hosting-Migrationen lohnt sich ein erneuter Check. Security Headers können durch Serverkonfigurationsänderungen leise verschwinden, ohne dass irgendetwas sichtbar kaputt geht.
Für wen sind Security Headers besonders wichtig?
Technisch sollte jede öffentliche WordPress-Website Security Headers setzen. Praktisch gibt es Fälle, wo der Aufwand besonders gut begründet ist:
WooCommerce-Shops verarbeiten Zahlungsdaten und Kundendaten – hier sind HSTS und eine strikte CSP keine Kür, sondern Pflicht.
Membership-Websites und Login-Bereiche profitieren besonders von X-Frame-Options und Cross-Origin-Opener-Policy, weil Clickjacking-Angriffe oft auf Login-Formulare abzielen.
Websites mit Kontaktformularen und Nutzereingaben sollten eine CSP haben, die Inline-Scripts einschränkt, um XSS-Vektoren zu reduzieren.
Agenturen und Freelancer, die Websites für Kunden betreiben, sollten Security Headers in ihr Standard-Setup aufnehmen. Es ist ein kleiner Aufwand mit messbarem Ergebnis – und erklärt sich Kunden gut, wenn du einen Score vorher/nachher zeigen kannst.
Security Headers gesetzt, aber willst du sicherstellen, dass deine CSP sauber konfiguriert ist? Nutze den CSP Generator von WP Helping Hand, um eine WordPress-kompatible Content Security Policy aufzubauen.
