Ein Team aktiviert HSTS und eine strikt durchgesetzte Content Security Policy gleichzeitig. Kurz darauf funktionieren der Checkout in einem externen Frame und mehrere Editor-Skripte nicht mehr; eine alte Subdomain ist wegen HSTS sogar nach dem Rollback unerreichbar. Sicherheitsheader entfalten große Wirkung, müssen aber kontrolliert eingeführt werden.
Sie erfahren, welche Header sich für WordPress eignen, wie Sie bestehende Abhängigkeiten erfassen und warum CSP sowie HSTS eine längere Beobachtungsphase benötigen.
Inhaltsverzeichnis
Was Sicherheitsheader leisten
HTTP-Response-Header geben dem Browser Regeln für Transport, zugelassene Inhaltsquellen, Einbettung, MIME-Typen, Referrer-Daten und Browserfunktionen vor. X-Content-Type-Options: nosniffverhindert beispielsweise das Erraten eines anderen Dateityps, während CSP steuert, aus welchen Quellen Skripte, Styles, Frames oder Fonts geladen werden dürfen.
HSTS weist Browser an, eine Domain künftig ausschließlich per HTTPS aufzurufen. Diese Entscheidung wird im Client gespeichert und lässt sich nicht durch das bloße Entfernen der Serverregel sofort zurücknehmen.
Ein realistisches WordPress-Beispiel
Eine WooCommerce-Website lädt Zahlungsframes, Consent-Skripte, Webfonts und Analytics von mehreren Anbietern. Eine kopierte CSP erlaubt nur die eigene Domain. Der Browser blockiert deshalb den Zahlungsframe und Inline-Code des Consent-Tools; zugleich ergänzt das CDN eine zweite CSP, die beide Richtlinien gemeinsam noch strenger macht.
Das Team bestimmt zunächst eine einzige zuständige Ebene und setzt CSP auf Report-Only. Erst nachdem alle benötigten Quellen erfasst und die kritischen Abläufe geprüft sind, wird die Richtlinie schrittweise erzwungen.
Warum eine schrittweise Einführung wichtig ist
Ein Scanner bewertet einen vorhandenen Header, kennt aber nicht die Geschäftsabläufe der Website. Eine pauschale Freigabe wie unsafe-inlinekann den beabsichtigten Schutz weitgehend entwerten; eine zu enge Richtlinie legt dagegen Editor, Formulare oder Checkout lahm.
Bei HSTS ist die Reichweite besonders wichtig. includeSubDomainsdarf erst eingesetzt werden, wenn wirklich jede betroffene Subdomain dauerhaft über gültiges HTTPS erreichbar ist. Preload erfordert zusätzliche Sorgfalt, weil die Aufnahme in Browserlisten nur langsam rückgängig gemacht werden kann.
Der sichere Einstieg
- Prüfen Sie die endgültigen Header am Origin und hinter CDN oder Reverse Proxy.
- Listen Sie Skript-, Style-, Font-, Frame- und API-Quellen sowie alle eingebundenen Dienste auf.
- Beginnen Sie mit risikoarmen Headern und testen Sie CSS, JavaScript, Downloads und Formulare.
- Führen Sie CSP zunächst als Report-Only-Richtlinie ein und werten Sie reale Verstöße aus.
- Aktivieren Sie HSTS erst nach einer vollständigen HTTPS-Prüfung aller betroffenen Hosts.
Testen Sie Block-Editor, Medienupload, Login, Passwort-Reset, Suche, Checkout, Zahlungsrückkehr, Consent, Analytics, Videos, Karten und Fonts. Ein sauberer Browser ohne alte HSTS- oder Cache-Zustände gehört ebenfalls zur Prüfung.
Die technische Umsetzung
Apache kann Header mit mod_headerssetzen. Verwenden Sie Bedingungen, damit dynamische und statische Antworten nicht versehentlich unterschiedliche oder doppelte Richtlinien erhalten. Prüfen Sie vor jeder Änderung, ob ein CDN vorhandene Werte ersetzt, ergänzt oder entfernt.
Eine CSP sollte auf einem belastbaren Quelleninventar beruhen. Nonces oder Hashes sind für kontrollierten Inline-Code besser geeignet als eine pauschale Freigabe. frame-ancestorsregelt, wer Ihre Seiten einbetten darf; falls zusätzlich X-Frame-Optionsverwendet wird, müssen beide dieselbe Absicht ausdrücken.
Dokumentieren Sie für jeden Header die zuständige Konfiguration, den fachlichen Zweck und das letzte geprüfte Datum. So lässt sich nach einem Theme-, Plugin-, CDN- oder Zahlungsanbieterwechsel gezielt erkennen, welche Richtlinie angepasst werden muss.
Risiken, Backup und Rollback
Kopierte CSP-Blöcke blockieren häufig notwendige Ressourcen. Doppelte Header können unerwartet zusammenwirken, und ein zu früh gesetztes HSTS mit Subdomain-Reichweite kann Dienste langfristig unzugänglich machen. Der Rollback einer Datei beendet nicht den bereits im Browser gespeicherten HSTS-Zustand.
Sichern Sie die aktive .htaccessund halten Sie einen unabhängigen Serverzugang bereit. Nehmen Sie Änderungen einzeln vor, damit sich Fehler eindeutig zuordnen lassen. Bei CSP kehren Sie zunächst zu Report-Only zurück; bei HSTS benötigen betroffene Clients Zeit, bis die festgelegte Gültigkeit abläuft.
Wie AIOWS unterstützt:
AIOWS Htaccess Editor
Für ausgewählte Sicherheitsheader bietet der AIOWS Htaccess Editor in unterstützten Apache-Umgebungen eine verwaltete Oberfläche für die aktive .htaccessund legt vor dem Speichern automatisch eine Sicherung an. Damit lassen sich ausgewählte Sicherheitsheader nachvollziehbar ergänzen, ohne den von WordPress verwalteten Rewrite-Block unnötig anzufassen.
Erfassen Sie zuerst die bereits am Origin und am CDN gesendeten Header. Fügen Sie anschließend jeweils nur die nächste geprüfte Richtlinie hinzu und kontrollieren Sie die resultierende Antwort im Browser. Für CSP gehören die Report-Only-Phase und echte Funktionsprüfungen zum Ablauf; bei HSTS muss die HTTPS-Abdeckung vor dem Speichern feststehen.
Das Modul kann keine CDN-Konfiguration ändern, keine CSP-Abhängigkeiten automatisch bestimmen und kein fehlendes TLS-Zertifikat ersetzen. Auch der im Browser gespeicherte HSTS-Zustand liegt außerhalb seiner Kontrolle. Ein separater Dateizugriff und ein dokumentierter Wiederherstellungsweg bleiben daher unverzichtbar.
Passende AIOWS-Artikel
- Verzeichnisauflistung in WordPress per .htaccess abschalten
- wp-config.php mit .htaccess schützen
- Browser-Cache-Header mit WordPress-.htaccess setzen
Fazit
Führen Sie Sicherheitsheader einzeln und mit klarer Zuständigkeit ein. CSP beginnt im Report-Only-Modus; HSTS folgt erst, wenn alle einbezogenen Hosts dauerhaft per HTTPS erreichbar sind. Entscheidend sind reale Funktionsprüfungen, nicht die bloße Bewertung eines Scanners.
