WordPress Security Header richtig einrichten – ohne Funktionen zu zerstören

Security Header sind Anweisungen, die dein Server jeder Antwort mitgibt und die dem Browser sagen, was er mit deiner Seite tun darf — und was nicht. Sie kosten nichts, wirken sofort und schützen deine Besucher vor ganzen Angriffsklassen. Aber: Ein falsch gesetzter Header kann Funktionen lautlos abschalten. Deshalb hier die ehrliche Sortierung: fünf gefahrlose, ein anspruchsvoller.

Die fünf gefahrlosen Header

1. X-Content-Type-Options — verhindert, dass der Browser Dateitypen „errät“ (MIME-Sniffing) und z. B. eine getarnte Datei als Skript ausführt:
   Header set X-Content-Type-Options "nosniff"
2. X-Frame-Options — verbietet das Einbetten deiner Seite in fremde iFrames und damit Clickjacking-Angriffe:
   Header set X-Frame-Options "SAMEORIGIN"
3. Referrer-Policy — begrenzt, welche URL-Informationen beim Klick auf externe Links mitgeschickt werden:
   Header set Referrer-Policy "strict-origin-when-cross-origin"
4. Permissions-Policy — schaltet Browser-Funktionen ab, die deine Seite nicht braucht (Kamera, Mikrofon, Standort):
   Header set Permissions-Policy "camera=(), microphone=(), geolocation=()"
5. Strict-Transport-Security (HSTS) — zwingt Browser, deine Seite künftig nur noch über HTTPS aufzurufen. Voraussetzung: HTTPS läuft vollständig und dauerhaft (sonst sperrst du Besucher aus!):
   Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
   Erst setzen, wenn Mixed Content restlos behoben ist.

So setzt du sie

Der sauberste Weg führt über die .htaccess im Hauptverzeichnis (Apache/LiteSpeed). Alle fünf Header in einen mit Kommentar markierten Block, Sicherungskopie vorher:

<IfModule mod_headers.c>
Header set X-Content-Type-Options "nosniff"
Header set X-Frame-Options "SAMEORIGIN"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>

Bei Nginx gehören die Zeilen in die Server-Konfiguration (add_header …) — das übernimmt der Hoster. Auch per Plugin geht es; bedenke nur: Header aus PHP greifen nicht für Ressourcen, die am PHP vorbei ausgeliefert werden (Caching!). Serverseitig gesetzt ist deshalb die robustere Wahl.

Der anspruchsvolle: Content-Security-Policy (CSP)

Die CSP ist der mächtigste Header — sie legt fest, von welchen Quellen Skripte, Styles und Bilder überhaupt geladen werden dürfen, und stoppt damit auch eingeschleustes Schadskript. Genau diese Macht macht sie riskant: Eine zu strenge CSP legt Page Builder, Google Fonts, Analytics oder YouTube-Einbettungen lautlos lahm.

Der seriöse Weg in drei Stufen:

1. Mit Content-Security-Policy-Report-Only starten — der Browser meldet Verstöße, blockiert aber nichts.
2. Berichte auswerten, Quellen-Liste verfeinern, bis keine legitimen Verstöße mehr auftreten.
3. Erst dann scharf schalten — und nach jedem neuen Plugin oder Tracking-Skript nachpflegen.

Für die meisten Websites ist eine gepflegte CSP ein Projekt, kein Häkchen. Die fünf Header oben zuerst — sie bringen 80 % des Nutzens bei 0 % Bruchrisiko.

Testen und verifizieren

• securityheaders.com bewertet deine Domain mit einer Schulnote und zeigt fehlende Header.
• Nach dem Setzen: Website vollständig durchklicken — Formulare, eingebettete Videos, Buchungs-Widgets. Besonders nach HSTS und CSP.
• Browser-Konsole (F12) im Blick: Blockierte Ressourcen tauchen dort sofort auf.

Im Shield-Modul von Ammera Care gehören Security Header zur 1-Klick-Härtung: Wir setzen die verträglichen Header serverseitig, prüfen das Ergebnis automatisch und lassen bewusst die Finger von einer pauschalen CSP — die zerlegt mehr Websites, als sie schützt. Zum Shield-Modul.