HTTP‑Sicherheits‑Header: WordPress-Setup (2026 Edition)
Wer 2026 eine Website betreibt, trägt Verantwortung für die Daten seiner Besucher. Was mich fassungslos macht: Erschreckend viele Agenturen liefern noch immer Projekte ohne grundlegende Sicherheits‑Header aus.
Dabei sind HTTP-Header die effektivste Verteidigungslinie: Sie kosten keine Performance, wirken sofort und stoppen Angriffe wie XSS, Clickjacking und Datenlecks im Keim.
- HTTP‑Sicherheits‑Header: WordPress-Setup (2026 Edition)
- Die wichtigsten Sicherheits‑Bausteine
- Mehrschichtige Sicherheits‑Architektur
- CSP: So restriktiv wie möglich – ohne Funktionsverlust
- Technische Voraussetzungen & Risiken
- Die WordPress‑Header‑Sektion für deine .htaccess (Standard 2026)
- FAQ: Die häufigsten Fragen
- Troubleshooting: Was tun, wenn etwas nicht funktioniert?
- Mein Fazit:
Ich zeige dir hier das Setup, mit dem ich meine Seite absichere – inklusive der Lösung für das größte Problem: Ein geschütztes System bei gleichzeitig voll funktionsfähigem WordPress‑Frontend und ‑Backend.
Die wichtigsten Sicherheits‑Bausteine
| Header | Nutzen in der Praxis |
|---|---|
| HSTS | Erzwingt HTTPS und verhindert Man‑in‑the‑Middle‑Angriffe. |
| X‑Frame‑Options | Clickjacking‑Schutz: Verhindert das Einbetten in fremde Seiten. |
| X‑Content‑Type‑Options | Stoppt MIME‑Sniffing (Schutz vor Schadcode in Uploads). |
| Referrer‑Policy | Schützt die Privatsphäre deiner Nutzer beim Verlassen der Seite. |
| COOP / CORP | Moderne Browser‑Isolation (Spectre/Meltdown‑Schutz). |
Mehrschichtige Sicherheits‑Architektur
HTTP‑Header sind eine starke erste Verteidigungslinie – aber sie decken nur den Browser‑Bereich ab. Für einen vollständigen Schutz braucht es zusätzliche Sicherheitsschichten auf Server‑ und Anwendungsebene. Auf seotologie.de nutze ich deshalb drei ergänzende Komponenten:
1. NinjaFirewall (WAF)
Blockiert Angriffe (Brute‑Force, SQL‑Injection), noch bevor WordPress überhaupt geladen wird.
2. Eigene Outbound‑Firewall
- WP_HTTP_BLOCK_EXTERNAL: Stoppt unkontrollierte Datenabflüsse.
- Whitelist‑System: Nur verifizierte APIs dürfen kontaktiert werden.
- Dashboard‑Logging: Volle Kontrolle über alle ausgehenden Anfragen.
3. Pattern‑Firewall & Honeypots
- Blockiert Exploit‑Scanner und erkennt Bot‑Traffic sofort.
- Framework‑Schutz: Erkennt Scans auf Next.js, GraphQL oder Vercel‑Strukturen.
- Honeypot‑Pfade: Lockt Angreifer in Sackgassen und sperrt deren IPs automatisiert.
CSP: So restriktiv wie möglich – ohne Funktionsverlust
Die Content‑Security‑Policy (CSP) ist das Herzstück der Absicherung – aber auch die größte Herausforderung. Moderne WordPress‑Themes wie Astra und viele Plugins arbeiten mit Inline‑JavaScript und Inline‑Styles. Ohne diese Inline‑Elemente wäre das Frontend schlicht nicht funktionsfähig.
Darum setze ich auf eine einheitliche, WordPress‑kompatible CSP, die sowohl im Frontend als auch im Backend stabil läuft. Sie ist so restriktiv wie möglich, aber bewusst tolerant genug, um Astra, Gutenberg, Navigation, Menüs und Plugins nicht zu blockieren.
- ‚unsafe-inline‘ bleibt notwendig – sonst bricht Astra.
- ‚unsafe-eval‘ wird vermieden – WordPress benötigt es nicht.
- Alle Quellen sind auf
'self'und HTTPS beschränkt.
Wichtig: Ein A+‑Rating ist mit Astra technisch nicht erreichbar. Das liegt nicht an der Sicherheit, sondern an der Architektur des Themes. Ein A‑Rating ist die realistische Obergrenze für ein voll funktionsfähiges WordPress‑Frontend.
Technische Voraussetzungen & Risiken
1. Apache & mod_headers
Damit die Sicherheits‑Header korrekt ausgeliefert werden, muss auf deinem Server das Modul
mod_headers aktiviert sein. Bei modernen Hostern wie IONOS, Strato, All‑Inkl oder
HostEurope ist das standardmäßig der Fall.
2. HSTS: Der stärkste, aber riskanteste Header
HSTS zwingt Browser, deine Seite ausschließlich über HTTPS zu laden – und das für die
Dauer des gesetzten max-age. Das erhöht die Sicherheit erheblich, bringt aber klare Risiken mit sich:
- Läuft dein SSL‑Zertifikat ab, ist die Seite für Besucher komplett gesperrt.
- Ein erzwungener HTTP‑Aufruf ist nicht mehr möglich – auch für dich selbst nicht.
- Mit
includeSubDomainsgilt der HTTPS‑Zwang für alle Subdomains.
3. Das CSP‑Problem
Die Content‑Security‑Policy ist extrem wirkungsvoll, kann aber Funktionen blockieren, ohne dass du es
sofort bemerkst. Die hier verwendete Konfiguration ist bewusst kompatibel gehalten
('unsafe-inline'), damit WordPress, Astra und Plugins fehlerfrei arbeiten.
- Externe Tools wie Analytics, Pixel oder Chat‑Widgets können blockiert werden.
- Plugins mit Inline‑Skripten funktionieren nur dank
'unsafe-inline'. - Eine zu strenge CSP kann Layouts und Interaktionen beeinträchtigen.
Wichtig: Nach jeder Änderung die Browser‑Konsole prüfen (F12 → Console).
4. Universal‑Kompatibilität
Die Vorlage ist so konzipiert, dass sie auf nahezu allen WordPress‑Installationen stabil läuft. Sie ist bewusst nicht maximal restriktiv, um volle Kompatibilität mit Themes und Plugins zu gewährleisten.
| Header | Risiko für Layout/Funktion |
|---|---|
| Strict‑Transport‑Security | Hoch, wenn SSL nicht stabil ist. |
| X‑Frame‑Options | Mittel, wenn du iFrames auf anderen Domains brauchst. |
| Permissions‑Policy | Gering, außer du brauchst Kamera/Mikrofon. |
| Content‑Security‑Policy | Mittel, kann externe Widgets blockieren. |
Die WordPress‑Header‑Sektion für deine .htaccess (Standard 2026)
Dieser Abschnitt ergänzt deine bestehende .htaccess um moderne Sicherheits‑Header.
Er ist für Apache‑Server optimiert und nutzt setifempty, um Konflikte mit
Hoster‑Vorgaben (z. B. IONOS, Strato, All‑Inkl) zu vermeiden.
Wenn du nach dem Einbau trotzdem kein „A“ erhältst, prüfe, ob ein Proxy wie Cloudflare
eigene Header überschreibt.
# SECURITY HEADERS BY SEOTOLOGIE (2026)
# 1. Transport & Framing
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header always set X-Frame-Options "SAMEORIGIN"
Header setifempty X-Content-Type-Options "nosniff"
Header always set X-XSS-Protection "0"
# 2. Privacy & Permissions
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(self), payment=(self), browsing-topics=()"
# 3. Cross-Origin Isolation
Header always set Cross-Origin-Opener-Policy "same-origin-allow-popups"
Header always set Cross-Origin-Resource-Policy "cross-origin"
Header always set Cross-Origin-Embedder-Policy "unsafe-none"
# 4. Content Security Policy (WordPress-kompatibel)
Header always set Content-Security-Policy "upgrade-insecure-requests; default-src 'self' https: data: blob:; script-src 'self' 'unsafe-inline' https:; style-src 'self' 'unsafe-inline' https:; img-src 'self' data: blob: https:; font-src 'self' data: https:; connect-src 'self' https: wss:; frame-src 'self' https:;"
# 5. Cleanup
Header always unset X-Powered-By
FAQ: Die häufigsten Fragen
Bekomme ich damit ein A+‑Rating?
Nein. Mit Astra und modernen WordPress‑Setups ist ein A+ realistisch nicht erreichbar, weil Inline‑Skripte technisch notwendig sind. Ein A‑Rating ist die sinnvolle Obergrenze bei voller Funktionalität.
Warum ist X‑XSS‑Protection auf „0“?
Der alte XSS‑Filter in Browsern ist veraltet und kann mehr schaden als nutzen. Moderne Absicherung erfolgt über CSP.
Funktionieren YouTube, Google Fonts und externe Widgets noch?
Ja, solange sie über HTTPS eingebunden werden und nicht durch eine zusätzliche, strengere CSP blockiert werden.
Warum ist ‚unsafe-inline‘ erlaubt?
In der Theorie unsicher, in der Praxis aber für Astra, Gutenberg und viele Plugins zwingend notwendig. Ohne ‚unsafe-inline‘ wäre das Frontend defekt.
Kann ich ‚unsafe-eval‘ entfernen?
Wenn kein Plugin eval() nutzt, ja. Einige Plugins verwenden jedoch eval‑ähnliche Konstrukte. Dann muss es erlaubt werden.
Was passiert, wenn ein Plugin eval() nutzt?
Dann blockiert die CSP das Plugin. In diesem Fall muss ‚unsafe-eval‘ ergänzt werden – oder das Plugin ersetzt werden.
Warum ist COEP auf unsafe-none gesetzt?
Weil WordPress, YouTube, Google Fonts und viele Plugins sonst blockiert würden. Vollständige Cross‑Origin‑Isolation ist im WordPress‑Umfeld nicht praktikabel.
Kann ich die Header auch per Plugin setzen?
Ja, aber nicht empfohlen. Plugins laden zu spät, können überschrieben werden und verursachen oft doppelte Header. Serverseitig ist stabiler.
Kann diese Konfiguration meine Seite „zerschießen“?
Nur, wenn deine Seite Inline‑Skripte oder externe Ressourcen nutzt, die nicht erlaubt sind. Deshalb ist die Vorlage bewusst kompatibel gehalten.
Warum sehe ich keine Änderungen nach dem Speichern?
Browser cachen Header aggressiv. Cache leeren oder privaten Modus nutzen. Bei HSTS kann der Browser alte Werte über Monate behalten.
Gibt es eine sicherere Alternative zu ‚unsafe-inline‘?
Ja: Nonces oder Hashes. Aber WordPress, Astra und viele Plugins unterstützen das nicht. Deshalb ist ‚unsafe-inline‘ die einzige realistische Option.
Was ist der Unterschied zwischen always set und setifempty?
always set überschreibt bestehende Header. setifempty setzt den Header nur, wenn keiner existiert – ideal bei Hostern, die eigene Header senden.
Troubleshooting: Was tun, wenn etwas nicht funktioniert?
1. Die Seite lädt, aber Funktionen fehlen (Slider, Menüs, Buttons)
Browser‑Konsole öffnen (F12 → Console). Wenn CSP‑Fehler angezeigt werden, blockiert die CSP Skripte oder Styles. Dann betroffene Domains freigeben.
2. YouTube, Google Maps oder externe Widgets laden nicht
Prüfen, ob die eingebundenen Domains in frame-src, script-src oder img-src erlaubt sind.
3. Das Backend (WP‑Admin) funktioniert nicht mehr richtig
Dann ist die CSP zu streng. Für das Backend sind ‚unsafe-inline‘ und WordPress‑kompatible Skript‑Quellen Pflicht.
4. Nach Aktivierung von HSTS ist die Seite nicht erreichbar
SSL prüfen, Zertifikat erneuern. HSTS kann nicht kurzfristig deaktiviert werden – der Browser speichert den Zustand.
5. Ein Plugin funktioniert plötzlich nicht mehr
Konsole prüfen. Wenn eval oder Inline‑Skripte blockiert werden, muss die CSP angepasst oder das Plugin ersetzt werden.
6. Ich möchte testen, ohne etwas zu blockieren
CSP als Content-Security-Policy-Report-Only senden. So werden Verstöße geloggt, aber nichts blockiert.
7. HTTPS wird weiter erzwungen, obwohl ich HSTS entfernt habe
Der Browser speichert HSTS bis zum Ablauf von max-age. Testen im privaten Modus oder mit anderem Browser.
Mein Fazit:
Sicherheit ist kein Zufall, sondern Konfiguration. Mit dieser WordPress Standard Vorlage schützt du deine Besucher und deine Infrastruktur nachhaltig – ohne dein WordPress‑Frontend oder ‑Backend unbenutzbar zu machen.
