Sichere HTTP-Sicherheits-Header analysieren

HTTP‑Sicherheits‑Header & Firewall: Das 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.

Inhaltsverzeichnis ausblenden

HTTP‑Sicherheits‑Header & Firewall: Das WordPress-Setup (2026 Edition)
Die wichtigsten Sicherheits‑Bausteine
Mehrschichtige Firewall‑Architektur
CSP‑Split: Maximale Härtung ohne Funktionsverlust
Technische Voraussetzungen & Risiken
Die WordPress .htaccess‑Vorlage (Standard 2026)
FAQ: Die häufigsten Fragen
Troubleshooting: Was tun, wenn etwas nicht funktioniert?
Fazit: Keine Ausreden mehr

Ich zeige dir hier das Setup, mit dem ich seotologie.de absichere – inklusive der Lösung für das größte Problem: Ein geschütztes System bei gleichzeitig voll funktionsfähigem WordPress‑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 Firewall‑Architektur

Header allein sind stark, aber sie ersetzen keine Firewall. Für seotologie.de setze ich auf drei Ebenen:

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‑Split: Maximale Härtung ohne Funktionsverlust

Die Content‑Security‑Policy (CSP) ist das Herzstück. Damit WordPress (Gutenberg, Plugins) und externe Medien (YouTube, Fonts) funktionieren, nutze ich einen hybriden Ansatz:

Frontend: Streng konfiguriert, aber HTTPS‑Quellen erlaubt.
Backend (WP‑Admin): Kompatibilitäts‑Modus für reibungsloses Arbeiten.

Technische Voraussetzungen & Risiken

1. Apache & mod_headers

Damit die Header funktionieren, 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 gefährlichste Header

HSTS zwingt Browser, deine Seite ausschließlich über HTTPS zu laden – und zwar für ein ganzes Jahr (max-age=31536000). Das ist extrem sicher, aber:

Wenn dein SSL‑Zertifikat abläuft, ist deine Seite komplett gesperrt.
Wenn du HTTP erzwingst, kommst du selbst nicht mehr auf die Seite.
Mit includeSubDomains gilt der Zwang auch für Subdomains.

3. Das CSP‑Problem

Die CSP ist mächtig – aber sie kann Funktionen blockieren, ohne dass du es sofort merkst. Die Vorlage ist bewusst „tolerant“ ('unsafe-inline'), damit WordPress nicht kaputt geht.

Externe Tools (Analytics, Pixel, Chat‑Widgets) können blockiert werden.
Plugins mit Inline‑Skripten funktionieren nur wegen 'unsafe-inline'.
Eine zu strenge CSP kann Layouts zerstören.

Wichtig: Nach jeder Änderung die Browser‑Konsole prüfen (F12 → Console).

4. Universal‑Kompatibilität

Die Vorlage ist ein sicheres Grundrauschen, das 99% aller WordPress‑Seiten nicht beschädigt. Sie ist bewusst nicht maximal restriktiv – dafür aber stabil.

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 .htaccess‑Vorlage (Standard 2026)

Optimiert für Apache‑Server. Verhindert durch setifempty Konflikte mit Hostern wie IONOS oder Strato.

# SECURITY HEADERS BY SEOTOLOGIE (2026)


    # 1. Transport & Framing
    # Achtung: HSTS sperrt deine Seite, wenn SSL kaputt ist!
    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 (kompatibel für WP, YouTube, Fonts)
    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 & sicher)
    # Kein 'unsafe-eval' (WordPress braucht es nicht)
    # 'unsafe-inline' bleibt für Gutenberg & Plugins notwendig
    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?

Ein theoretisches A+ verlangt das Verbot von 'unsafe-inline'. Das würde WordPress zerstören. Diese Vorlage bietet den höchstmöglichen Schutz in der realen Praxis.

Warum ist X-XSS-Protection auf „0“?

Weil moderne Browser die CSP nutzen. Der alte Filter ist unsicher und wird deaktiviert.

Funktionieren YouTube, Google Fonts und externe Widgets noch?

Ja. Dank https: in der CSP bleiben alle sicheren externen Quellen erlaubt.

Was bedeutet browsing-topics=()?

Es verhindert, dass Browser Interessenprofile für Werbenetzwerke erstellen.

Warum ist HSTS so gefährlich?

HSTS zwingt Browser ein Jahr lang zu HTTPS. Wenn dein SSL-Zertifikat abläuft oder kaputt ist, ist deine Seite komplett gesperrt. Deshalb nur aktivieren, wenn SSL stabil läuft.

Was mache ich, wenn nach der Aktivierung etwas nicht mehr funktioniert?

Öffne die Browser-Konsole (F12 → „Console“). Rote Fehlermeldungen zeigen dir genau, welche Ressource blockiert wurde. Meist liegt es an der CSP.

Warum ist 'unsafe-inline' erlaubt? Ist das nicht unsicher?

Ja, es ist ein Kompromiss. WordPress, Gutenberg und viele Plugins funktionieren ohne 'unsafe-inline' nicht. Ohne diesen Wert wäre dein Backend unbenutzbar.

Kann ich 'unsafe-eval' entfernen?

Ja. WordPress benötigt es nicht. Deshalb ist es in dieser optimierten Version bereits entfernt – ein großer Sicherheitsgewinn.

Was passiert, wenn ein Plugin doch eval() nutzt?

Dann erscheinen in der Browser-Konsole Fehlermeldungen wie: “Refused to evaluate a string as JavaScript because ‚unsafe-eval‘ is not allowed…”. Das ist ein Zeichen für veralteten oder schlecht programmierten Code. Du solltest das Plugin ersetzen.

Warum ist COEP auf unsafe-none gesetzt?

Weil YouTube, Google Fonts, iFrames und viele externe Dienste sonst nicht mehr funktionieren würden. unsafe-none ist der einzige realistische Wert für WordPress.

Kann ich die Header auch per Plugin setzen?

Ja, z. B. mit „Really Simple SSL“. Aber: Die .htaccess‑Variante ist sicherer und schneller, weil sie greift, bevor PHP geladen wird.

Was mache ich, wenn mein Hoster eigene Header setzt?

Die Vorlage nutzt setifempty, um Konflikte zu vermeiden. Falls dein Hoster trotzdem Header überschreibt, musst du sie im Hosting‑Panel deaktivieren.

Kann diese Konfiguration meine Seite „zerschießen“?

Nein. Die Vorlage ist bewusst so gestaltet, dass sie 99 % aller WordPress‑Seiten nicht beschädigt. Trotzdem solltest du nach der Aktivierung testen.

Warum sehe ich keine Änderungen, nachdem ich die .htaccess gespeichert habe?

Das liegt meist am Server-Caching (z. B. Varnish, Nginx FastCGI Cache) oder an einem Cache‑Plugin. Leere alle Caches und teste im Inkognito‑Modus. Du kannst die Header auch extern prüfen, z. B. mit securityheaders.com.

Gibt es eine sicherere Alternative zu 'unsafe-inline'?

Ja: Nonces oder Hashes. Aber: WordPress müsste jedes Skript dynamisch signieren. Ohne tiefgreifende Programmierung oder spezielle Plugins ist das nicht realistisch umsetzbar.

Was ist der Unterschied zwischen always set und setifempty?

always set erzwingt den Header immer – auch bei 404‑ oder 500‑Fehlern. setifempty setzt den Header nur, wenn er nicht bereits existiert. Das verhindert doppelte Header, die manche Browser verwirren.

Troubleshooting: Was tun, wenn etwas nicht funktioniert?

1. Die Seite lädt, aber Funktionen fehlen (Slider, Menüs, Buttons)

Öffne die Browser-Konsole (F12 → Console). Wenn dort CSP‑Fehler stehen, blockiert die CSP ein Skript. Meist fehlt eine externe Domain oder ein Plugin nutzt Inline‑Code.

2. YouTube, Google Maps oder externe Widgets laden nicht

Prüfe, ob die Ressource über https: geladen wird. Unsichere (http) Inhalte werden blockiert. Falls ein Dienst eigene Domains nutzt, müssen diese in die CSP aufgenommen werden.

3. Das Backend (WP‑Admin) funktioniert nicht mehr richtig

Gutenberg benötigt 'unsafe-inline'. Wenn du eine zu strenge CSP nutzt, bricht der Editor. Lösung: Die WordPress‑kompatible CSP aus der Vorlage verwenden.

4. Nach Aktivierung von HSTS ist die Seite nicht erreichbar

Das SSL‑Zertifikat ist fehlerhaft. HSTS erzwingt HTTPS und blockiert HTTP komplett. Lösung: SSL reparieren, dann erneut testen.

5. Ein Plugin funktioniert plötzlich nicht mehr

Viele Plugins laden externe Skripte. Prüfe die Konsole: Dort steht genau, welche Domain blockiert wurde. Diese Domain muss ggf. in die CSP aufgenommen werden.

6. Ich möchte testen, ohne etwas zu blockieren

Nutze die CSP im Report‑Only‑Modus. Dann wird nichts blockiert, aber alle Verstöße erscheinen in der Konsole.

7. Ich habe die Zeilen gelöscht, aber die Seite erzwingt immer noch HTTPS

Das ist die „Falle“ von HSTS. Dein Browser hat sich gemerkt, dass die Seite nur per HTTPS erreichbar sein darf. Du musst den HSTS‑Cache manuell löschen (Chrome: chrome://net-internals/#hsts).

Fazit: Keine Ausreden mehr

Sicherheit im Web 2026 ist kein Zufall, sondern Konfiguration. Mit dieser Vorlage schützt du deine Besucher und deine Infrastruktur nachhaltig.

Nächste Schritte: Kopiere die Vorlage in deine .htaccess und teste das Ergebnis.