Diese Checkliste zeigt, welche HTTP-Security-Header für WordPress-Websites wirklich zählen – inklusive Prioritäten, Beispiel-Konfigurationen (Apache/Nginx) und Praxis-Schritten.
Fokus: HSTS, CSP, Permissions-Policy, Referrer-Policy, X-Content-Type-Options, X-Frame-Options, COOP/CORP. Klingt technisch? Erklären wir.
Am Ende erhalten Sie eine kompakte To-do-Liste, typische Fehler und einen CTA zu unserem Wartungspaket.
Warum Security-Header?
HTTP-Security-Header ergänzen Ihre Sicherheit direkt im Browser: Sie reduzieren XSS, Clickjacking, Datenabfluss und Mixed-Content-Risiken – oft mit wenigen Zeilen Server-Konfiguration. Diese Security Header basieren auf dem HTTP Protokoll und sichern die Kommunikation zwischen Browser und Webserver ab. HTTP Headers, insbesondere HTTP Response Header, übermitteln sicherheitsrelevante Anweisungen und Metadaten an den Browser, um die Verarbeitung und Anzeige von Inhalten zu steuern und so die Absicherung Ihrer Webanwendungen und eingebundenen Anwendungen zu unterstützen. Die Integration von Security Headern stellt eine wichtige Sicherheitsmaßnahme dar, um die Sicherheitsebene Ihrer gesamten Webseite und ihrer Anwendungen zu erhöhen. OWASP und MDN führen die wichtigsten Header samt Best-Practices und Beispielwerten. cheatsheetseries.owasp.org+1
Die Header – Prioritäten & Beispiele
Legende: P1 = Muss, P2 = Soll, P3 = Kann
P1 – Strict-Transport-Security (HSTS)Erzwingt dauerhaft HTTPS (keine Downgrades/Bypass). Empfohlen: max-age ≥ 6–12 Monate, includeSubDomains, optional preload (nur mit Sorgfalt). Beispiel:Strict-Transport-Security: max-age=31536000; includeSubDomains; preload Hinweis: „preload“ ist eine Browser-Liste, keine RFC-Direktive; Anforderungen prüfen (u. a. HTTPS überall, includeSubDomains). MDN Web Docs+2infosec.mozilla.org+2HTTP Strict Transport Security erhöht die Sicherheit der Kommunikation zwischen Browsern und Servern, indem es ausschließlich verschlüsselte Verbindungen zulässt.
P1 – Content-Security-Policy (CSP)Begrenzt, von wo Ressourcen/JS geladen werden. Starten Sie defensiv mit default-src ‘self’ und fügen Sie gezielt Quellen hinzu. Für eine sanfte Einführung eignet sich Content-Security-Policy-Report-Only. Beispiel (Basis):Content-Security-Policy: default-src ‘self’; img-src ‘self’ data:; script-src ‘self’; object-src ‘none’; base-uri ‘self’; frame-ancestors ‘none’ Tipp: Arbeiten Sie iterativ (Report-Only, Reports auswerten, verschärfen). MDN Web Docs+2MDN Web Docs+2Content Security Policy Headers definieren eine Whitelist erlaubter Quellen und helfen, Cross Site Scripting Angriffe (XSS) zu verhindern. Beim Einrichten der Content Security Policy sollten auch Content Delivery Networks (CDNs) als externe Quellen berücksichtigt werden, um eine sichere und funktionierende Webseite zu gewährleisten.
P2 – Permissions-PolicySteuert Browser-Features (z. B. Kamera, Geolocation, Autoplay). Beispiel blockt vieles global: Permissions-Policy: geolocation=(), camera=(), microphone=(), fullscreen=(self) Status: Spezifikation/Support im Blick behalten. MDN Web Docs+2MDN Web Docs+2Der Permissions Policy Header ist der Nachfolger der Feature Policy und steuert den Zugriff auf Browser-APIs, um die Privatsphäre der Nutzer zu schützen.
P2 – Referrer-PolicyBegrenzt Übermittlung des Referer (Datensparsamkeit). Beispiel: Referrer-Policy: no-referrer-when-downgrade oder strenger strict-origin-when-cross-origin. MDN Web Docs+1
P2 – X-Content-Type-OptionsVerhindert MIME-Sniffing: Beispiel: X-Content-Type-Options: nosniff cheatsheetseries.owasp.orgDas korrekte Setzen von MIME Typ und MIME Typen ist entscheidend, um Dateien vor unerwünschtem Zugriff zu schützen und Sicherheitslücken wie Cross-Site Scripting zu verhindern.
P2 – X-Frame-OptionsVerhindert Clickjacking via Frames (ergänzend zu frame-ancestors in CSP). Beispiel: X-Frame-Options: DENY oder SAMEORIGIN. (CSP ist moderner; beide parallel schadet nicht.) cheatsheetseries.owasp.org
P3 – Cross-Origin-Opener-Policy (COOP)Unterbindet gefährliche Cross-Origin-Interaktionen (Isolierung): Beispiel: Cross-Origin-Opener-Policy: same-origin P3 – Cross-Origin-Resource-Policy (CORP)Schützt Ressourcen vor Fremd-Einbindung: Beispiel: Cross-Origin-Resource-Policy: same-origin (Beide werden in OWASP/MDN aufgegriffen; prüfen Sie Kompatibilität zu Ihren Integrationen.) cheatsheetseries.owasp.org
Optional / Kontextspezifisch:
-
Cross-Origin-Embedder-Policy: require-corp (für strikte Isolierung/WebAssembly-Szenarien)
-
Reporting-Endpoints (CSP/COOP Reports sammeln)
-
Upgrade-Insecure-Requests (CSP-Direktive gegen Mixed Content) MDN Web Docs
Security Headers steuern, wie der Inhalt und die Dateien einer Webseite im Browser verarbeitet werden, und schützen so vor verschiedenen Angriffen. Sie können Security Headers sowohl über die .htaccess-Datei als auch durch das Installieren eines Plug-ins im entsprechenden Menüpunkt im WordPress-Backend setzen.
Bereit für’s nächste Level Ihrer Webseite?
Jetzt Ihre individuelle WordPress Beratung vereinbaren.
*100% kostenlos & unverbindlich
Kompakte Checkliste (Empfohlene Startwerte)
Header | Startwert (Beispiel) | Ziel |
|---|---|---|
HSTS | max-age=31536000; includeSubDomains; preload | HTTPS erzwingen |
CSP | default-src ’self‘; img-src ’self‘ data:; script-src ’self‘; object-src ’none‘; base-uri ’self‘; frame-ancestors ’none‘ | XSS/Mixed Content minimieren |
Permissions-Policy | geolocation=(), camera=(), microphone=() | Browser-Features einschränken |
Referrer-Policy | strict-origin-when-cross-origin | Datenschutz |
X-Content-Type-Options | nosniff | MIME-Sniffing verhindern |
X-Frame-Options | DENY | Clickjacking verhindern |
COOP/CORP | same-origin / same-origin | Isolierung von Kontexten |
Content Security Policy (CSP) – Schutz vor Code-Injektionen
Die Content Security Policy (CSP) ist einer der wichtigsten HTTP-Sicherheitsheader, wenn es um den Schutz Ihrer WordPress-Website vor Code-Injektionen und Cross Site Scripting (XSS) geht. Mit einer gezielten CSP-Richtlinie legen Sie fest, aus welchen Quellen Inhalte wie Skripte, Stylesheets oder Bilder geladen werden dürfen. So verhindern Sie, dass Angreifer schädlichen Code über unsichere Drittquellen einschleusen.
Die Konfiguration der Content Security Policy kann direkt in der „` .htaccess
-Datei Ihres Webservers erfolgen oder – besonders für WordPress – über ein spezialisiertes Plugin wie „Headers Security Advanced & HSTS WP“. Dieses Plugin erleichtert die Verwaltung und das Testen von CSP-Regeln, ohne dass Sie direkt an Serverdateien arbeiten müssen.
Ein typisches Beispiel für eine CSP-Richtlinie sieht so aus:
Content-Security-Policy: default-src ’self‘; script-src ’self‘ https://cdn.example.com; object-src ’none‘
Damit erlauben Sie Skripte nur von Ihrer eigenen Domain und einem definierten Content Delivery Network (CDN). Alle anderen Quellen werden blockiert, was das Risiko von Code-Injektionen deutlich reduziert. Für komplexere Setups empfiehlt sich die schrittweise Einführung der CSP im Report-Only-Modus, um eventuelle Probleme frühzeitig zu erkennen und zu beheben.
Die konsequente Nutzung der Content Security Policy – ob per Datei oder Plugin – ist ein zentraler Baustein moderner HTTP-Sicherheitsheader und sollte in keinem WordPress-Sicherheitskonzept fehlen.Feature Policy – Kontrolle über Browser-Features
Mit der Feature Policy, heute meist als Permissions Policy bezeichnet, steuern Sie gezielt, welche Browser-Features auf Ihrer Website genutzt werden dürfen. So können Sie beispielsweise den Zugriff auf Mikrofon, Kamera oder Standortdaten für Ihre Besucher unterbinden und damit sowohl die Sicherheit als auch den Datenschutz auf Ihrer WordPress-Seite erhöhen.
Die Konfiguration erfolgt entweder direkt in der „` .htaccess
-Datei oder komfortabel über ein Plugin, das die Verwaltung von HTTP-Sicherheitsheadern unterstützt. Ein gängiges Beispiel für eine restriktive Feature Policy ist:
Permissions-Policy: geolocation=(), microphone=(), camera=()
Mit dieser Einstellung verhindern Sie, dass Webseiten oder eingebettete Inhalte auf Standort, Mikrofon oder Kamera zugreifen können. Gerade bei WordPress-Websites, die viele externe Inhalte oder Plugins einbinden, ist dies ein wichtiger Schutzmechanismus gegen unerwünschte Zugriffe durch Browser-APIs.
Die gezielte Steuerung von Browser-Features über die Feature Policy ist ein effektiver Weg, die Angriffsfläche Ihrer Website zu minimieren und die Kontrolle über sensible Funktionen zu behalten.Bereit für’s nächste Level Ihrer Webseite?
Jetzt Ihre individuelle WordPress Beratung vereinbaren.
*100% kostenlos & unverbindlich
Cross Site Scripting (XSS) Schutz – Angriffsvektoren minimieren
Cross Site Scripting (XSS) zählt zu den häufigsten und gefährlichsten Angriffsvektoren auf moderne Webseiten. Angreifer versuchen dabei, schädlichen Code in Ihre Website einzuschleusen, um Daten zu stehlen oder Besucher zu kompromittieren. Um XSS-Angriffe effektiv abzuwehren, sollten Sie mehrere Schutzmaßnahmen kombinieren.
Zentral ist der Einsatz von HTTP-Sicherheitsheadern wie der Content Security Policy (CSP) und X-Content-Type-Options. Die CSP begrenzt, welche Skripte und Inhalte geladen werden dürfen, während X-Content-Type-Options das sogenannte MIME-Sniffing unterbindet und so das Ausführen von nicht autorisierten Skripten erschwert.
Darüber hinaus ist es essenziell, alle Benutzereingaben auf Ihrer WordPress-Website sorgfältig zu validieren und zu entschärfen. Plugins, die Formulare oder Kommentarfunktionen bereitstellen, sollten regelmäßig auf Updates geprüft und sicher konfiguriert werden. Auch das WordPress-Core-System sowie alle installierten Plugins und Themes müssen stets aktuell gehalten werden, um bekannte Schwachstellen zu schließen.
Mit einer Kombination aus Content Security Policy, X-Content-Type-Options und konsequentem Update-Management schaffen Sie eine solide Sicherheitsbasis gegen Cross Site Scripting XSS und andere Angriffe auf Ihre Website.
Praxis: So setzen Sie es in WordPress um
Diese Anleitung zeigt Schritt für Schritt, wie Sie Security Headers in WordPress integrieren und so die Absicherung Ihrer Webseite verbessern.
Server-Ebene bevorzugen
Setzen Sie Security-Header so früh wie möglich auf Webserver/CDN-Ebene (früh im Request-Pfad wirkt am besten). Die Integration über Plugins ist möglich, aber serverseitig ist robuster. (Siehe OWASP Übersicht & MDN Richtlinien.) cheatsheetseries.owasp.orgApache (.htaccess) – im Webroot ergänzen:
# HSTS (nur aktivieren, wenn 100% HTTPS, inkl. Subdomains!)
< IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header set X-Content-Type-Options "nosniff"
Header set X-Frame-Options "DENY"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Permissions-Policy "geolocation=(), camera=(), microphone=()"
Header set Content-Security-Policy "default-src 'self'; img-src 'self' data:; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'"
Header set Cross-Origin-Opener-Policy "same-origin"
Header set Cross-Origin-Resource-Policy "same-origin"
< /IfModule>
MDN/OWASP beschreiben Wirkung und Direktiven; testen Sie auf Staging. MDN Web Docs+2MDN Web Docs+2
Nginx – in server { … }:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), camera=(), microphone=()" always;
add_header Content-Security-Policy "default-src 'self'; img-src 'self' data:; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'" always;
add_header Cross-Origin-Opener-Policy "same-origin" always;
add_header Cross-Origin-Resource-Policy "same-origin" always;
Security Headers per Plug-in installieren
Alternativ können Sie ein geeignetes Plug-in installieren, um die Integration der HTTP Security Headers in WordPress zu erleichtern. Navigieren Sie dazu im WordPress-Backend zum entsprechenden Menüpunkt „Plugins“ und wählen Sie ein Security-Header-Plugin aus. Das Installieren eines solchen Plugins ist eine einfache Möglichkeit, ohne direkte Änderungen an den Dateien die gewünschten Header hinzuzufügen.CSP iterativ ausrollen
Start: Content-Security-Policy-Report-Only: …
Sammeln: Reporting-Endpoint (oder Server-Logs)
Anpassen: Quellen whitelisten, Inline-Skripte eliminieren, Nonces/Hashes nutzen
Live schalten: Content-Security-Policy: … (ohne Report-Only) MDN Web Docs+1
Tests & Monitoring
Browser-Konsole (CSP-Verstöße)
Security-Scanner (z. B. Mozilla Observatory / Header-Checks)
Nach Deployments erneut prüfen (Plugins/Themes können neue Quellen einführen). infosec.mozilla.org
Testen von HTTP Security Header-Einstellungen
Nach der Implementierung Ihrer HTTP-Sicherheitsheader ist es entscheidend, die Einstellungen regelmäßig zu testen. Nur so stellen Sie sicher, dass Ihre Website optimal vor Angriffen geschützt ist und die Header wie gewünscht funktionieren.
Für den Test von HTTP Security Headern stehen Ihnen verschiedene Tools zur Verfügung. Besonders beliebt ist SecurityHeaders.com: Hier geben Sie einfach Ihre Website-URL ein und erhalten eine detaillierte Auswertung, welche Header gesetzt sind und wo noch Optimierungsbedarf besteht. Auch Browser-Entwicklertools zeigen im Netzwerk-Tab die gesetzten HTTP-Header an.
Regelmäßige Überprüfungen sind wichtig, da Updates von WordPress, Plugins oder Serverkonfigurationen die Header unbeabsichtigt verändern oder entfernen können. Planen Sie daher nach jedem größeren Update einen erneuten Test ein, um die Sicherheit Ihrer Website dauerhaft auf hohem Niveau zu halten.
Mit konsequentem Monitoring und gezielten Tests Ihrer HTTP Security Header schützen Sie Ihre Website zuverlässig vor aktuellen Angriffsvektoren.
Häufige Fehler vermeiden
Ohne Backup upgraden – kein vertretbares Risiko.
Direkt auf Live aktualisieren – immer zuerst Staging.
Kompatibilitätsprobleme nicht prüfen – Bei der PHP-Umstellung können Kompatibilitätsprobleme mit Plugins oder Themes auftreten. Vor dem Aktualisierungsprozess sollten alle Erweiterungen auf ihre Kompatibilität getestet werden.
Fehlerbehebungen und Security Fixes ignorieren – Neue PHP-Versionen enthalten zahlreiche Fehlerbehebungen und Security Fixes, die die Sicherheit und Stabilität der Seiten erhöhen. Veraltete Versionen erhalten keine Sicherheitsfixes mehr und stellen ein erhebliches Risiko dar.
Alte PHP-Branches betreiben – z. B. 8.1 ist Ende 2025 am Sicherheits-EOL. php.net
Site Health ignorieren – wichtige Hinweise bleiben unbemerkt. WordPress.org
Probleme nicht recherchieren – Bei einem Problem nach der PHP-Umstellung oder bei Unsicherheiten empfiehlt es sich, in Foren nach Lösungen zu suchen oder Erfahrungen anderer Kunden zu nutzen.
