Wenn du Sicherheitsheader setzen willst, beginnst du mit vier Headern, die fast nie etwas kaputt machen: X-Content-Type-Options, Referrer-Policy, Permissions-Policy und ein Schutz gegen das Einbetten in fremde Seiten (X-Frame-Options bzw. frame-ancestors). HSTS führst du danach stufenweise ein, und die Content Security Policy testest du zuerst im reinen Berichtsmodus. Am zuverlässigsten setzt du alle Header auf Serverebene, weil Caching-Plugins Seiten oft ausliefern, ohne dass WordPress-Code läuft.
Was sind Sicherheitsheader und wovor schützen sie?
Sicherheitsheader sind Zeilen in der HTTP-Antwort deines Servers. Sie sagen dem Browser, was er mit deiner Seite tun darf und was nicht: ob er sie nur über HTTPS laden soll, ob andere Websites sie in einem Rahmen anzeigen dürfen, welche Skriptquellen erlaubt sind oder ob er Kamera und Standort freigeben darf. Der Schutz wirkt also im Browser deiner Besucher.
Wichtig ist die Einordnung: Sicherheitsheader schließen keine Sicherheitslücke in einem Plugin. Sie begrenzen den Schaden, wenn etwas schiefgeht. MDN formuliert das für die Content Security Policy deutlich: Sie ist kein Ersatz für saubere Eingabeprüfung, sondern eine zusätzliche Schutzschicht. Aktuelle Software bleibt die Grundlage – wie du WordPress-Sicherheitsupdates schnell und sicher einspielst, haben wir gesondert beschrieben.
Welche Sicherheitsheader brauchst du wirklich?
Die folgende Übersicht orientiert sich an den Empfehlungen des OWASP HTTP Headers Cheat Sheet und der MDN-Dokumentation. Die Werte sind für eine typische WordPress-Website angepasst.
| Header | Empfohlener Wert | Schützt vor | Risiko beim Einführen |
|---|---|---|---|
| X-Content-Type-Options | nosniff |
Ausführen von Dateien mit falschem Dateityp, etwa hochgeladener Dateien als Skript | gering, sofern dein Server korrekte Content-Types sendet |
| Referrer-Policy | strict-origin-when-cross-origin |
Weitergabe vollständiger URLs samt Parametern an fremde Websites | gering |
| Permissions-Policy | camera=(), microphone=(), geolocation=() |
Missbrauch von Browserfunktionen durch eingebettete Inhalte | gering, wenn du die Funktionen nicht nutzt |
| X-Frame-Options / frame-ancestors | SAMEORIGIN bzw. frame-ancestors 'self' |
Clickjacking: deine Seite unsichtbar in einer fremden Seite | gering; nur gewollte Einbettungen auf fremden Seiten fallen weg |
| Strict-Transport-Security (HSTS) | stufenweise bis max-age=31536000 oder mehr |
Abfangen unverschlüsselter Verbindungen | hoch bei Zertifikatsproblemen oder Subdomains ohne HTTPS |
| Content-Security-Policy | individuell, erst als Report-Only |
Cross-Site-Scripting und eingeschleuste Skripte | hoch: falsche Regeln blockieren Skripte, Schriften oder Tracking |
Welche Header kannst du weglassen?
X-XSS-Protection ist laut MDN veraltet und nicht standardisiert und kann in manchen Fällen selbst Lücken öffnen. OWASP empfiehlt, ihn wegzulassen oder auf 0 zu setzen. Auch der alte Name Feature-Policy ist durch Permissions-Policy ersetzt. Die Header Server und X-Powered-By sind keine Schutzheader, verraten aber Software und Versionen. Wenn dein Hosting es erlaubt, entfernst oder kürzt du sie.
Wie setzt du Sicherheitsheader Schritt für Schritt?
1. Den Ausgangszustand messen
Prüfe zuerst, was dein Server heute schon sendet. Das kostenlose HTTP Observatory von MDN analysiert die Header einer Adresse und gibt Empfehlungen. Beachte: Jeder kann jede Domain scannen, und der Scanverlauf einer Domain ist öffentlich einsehbar. Eine neue Prüfung ist frühestens nach 60 Sekunden möglich. Alternativ öffnest du in den Entwicklertools deines Browsers den Tab „Netzwerk“, lädst die Seite neu, klickst auf das erste Dokument und liest die Antwort-Header.
Prüfe dabei mindestens drei Adressen: die Startseite, einen Beitrag und die Anmeldeseite. WordPress sendet für Anmeldung und Adminbereich bereits selbst einen Rahmenschutz über die Funktion send_frame_options_header() mit X-Frame-Options: SAMEORIGIN und frame-ancestors 'self'. Für normale Seiten gilt das nicht automatisch.
2. Den richtigen Ort für die Header wählen
Du hast drei Möglichkeiten: die Serverkonfiguration (.htaccess bei Apache, Konfigurationsdatei bei nginx), ein Plugin oder PHP-Code mit dem Hook send_headers. Die Serverebene ist meist die beste Wahl, aus einem praktischen Grund: Caching. WP Super Cache liefert im Expertenmodus zwischengespeicherte Seiten laut Entwicklerdokumentation direkt über den Webserver aus, „ohne PHP-Code auszuführen“. Header, die erst ein WordPress-Hook setzt, fehlen dann genau auf den Seiten, die die meisten Besucher sehen.
Bei Apache verwendest du Header always set. Das Wort always sorgt laut Apache-Dokumentation dafür, dass der Header auch bei Fehlerseiten und Weiterleitungen gesendet wird. Bei nginx ergänzt du always an add_header. Achte bei nginx außerdem auf eine Stolperfalle: add_header-Angaben werden nur dann aus der übergeordneten Ebene übernommen, wenn im aktuellen Block kein eigenes add_header steht. Ein einzelner Cache-Header in einem location-Block kann so alle Sicherheitsheader für diesen Bereich abschalten. Wenn du keinen Zugriff auf die Serverkonfiguration hast, frag deinen Hoster. Woran du ein passendes Hosting erkennst, zeigt unser Beitrag zum WordPress-Hosting-Check.
3. Die risikoarmen Header zuerst setzen
Beginne mit X-Content-Type-Options, Referrer-Policy, Permissions-Policy und dem Rahmenschutz. Bei der Referrer-Policy legst du mit strict-origin-when-cross-origin ausdrücklich fest, was moderne Browser laut MDN ohnehin als Standard nutzen: Fremde Seiten erfahren nur deine Domain, nicht die vollständige Adresse. Für den Rahmenschutz nimmst du SAMEORIGIN statt DENY. Der Customizer und viele Page-Builder zeigen deine Seite in einem Rahmen auf derselben Domain an. Mit DENY würdest du dir diese Werkzeuge selbst blockieren.
Bei der Permissions-Policy sperrst du nur Funktionen, die du nicht brauchst. Bindest du etwa eine Karte mit Standortfreigabe ein, darf geolocation nicht auf () stehen. MDN weist außerdem darauf hin, dass nicht alle verbreiteten Browser den Header unterstützen. Er ist also eine Ergänzung, kein alleiniger Schutz.
4. HSTS stufenweise einführen
HSTS weist den Browser an, deine Domain für die angegebene Zeit nur noch über HTTPS aufzurufen. Gleichzeitig können Besucher bei einem Zertifikatsfehler die Warnung nicht mehr wegklicken. Läuft dein Zertifikat ab oder hat eine Subdomain kein HTTPS, sperrst du Besucher für die gesamte Laufzeit aus. Deshalb empfiehlt hstspreload.org eine Einführung in Stufen: 5 Minuten (max-age=300), dann eine Woche (604800), dann einen Monat (2592000), jeweils mit Beobachtung.
Den Zusatz includeSubDomains setzt du nur, wenn wirklich jede Subdomain HTTPS beherrscht. Den Zusatz preload lässt du zunächst weg. Die Aufnahme in die Preload-Liste der Browser setzt mindestens ein Jahr Laufzeit voraus, dauert Monate und lässt sich nur schwer rückgängig machen.
5. Die Content Security Policy im Testmodus beginnen
Die Content Security Policy ist der wirksamste, aber auch der empfindlichste Header. Sie legt fest, von wo Skripte, Styles, Bilder und Schriften geladen werden dürfen. WordPress-Websites binden häufig Inline-Skripte, Schriften, Videos, Consent-Banner und Analyse-Tools ein. Eine zu strenge Regel blockiert dann sichtbar Funktionen.
Starte deshalb mit Content-Security-Policy-Report-Only. Dieser Header blockiert nichts, meldet aber Verstöße in der Browserkonsole oder an eine Berichtsadresse. Ein sinnvoller erster Baustein, den du auch direkt scharf schalten kannst, ist upgrade-insecure-requests: Der Browser lädt dann eingebundene HTTP-Adressen über HTTPS. MDN betont, dass das HSTS nicht ersetzt. MDN rät von 'unsafe-inline' ab, weil es einen großen Teil des Schutzes aufhebt. In der Praxis brauchen viele WordPress-Themes es für Styles. Notiere solche Ausnahmen bewusst, statt sie ungeprüft zu übernehmen.
6. Ergebnis prüfen und dokumentieren
Lösche nach jeder Änderung den Seitencache und prüfe die drei Testadressen erneut, zusätzlich im privaten Fenster. Teste dann die wichtigen Funktionen: Kontaktformular, Warenkorb und Kasse, eingebettete Videos, Consent-Banner, Anmeldung und den Editor. Halte fest, welche Header mit welchem Wert seit wann aktiv sind. Das hilft dir, wenn nach einem Plugin-Update plötzlich etwas blockiert wird – gerade bei neuen Plugins, die du vor der Installation prüfst.
Wie sieht eine Beispielkonfiguration für Apache aus?
Das folgende Beispiel für die .htaccess enthält die risikoarmen Header, HSTS in der ersten Teststufe und eine CSP im Berichtsmodus. Lege vorher eine Sicherungskopie der Datei an. Ein Tippfehler in der .htaccess kann die ganze Website mit einem Serverfehler lahmlegen.
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Strict-Transport-Security "max-age=300"
Header always set Content-Security-Policy "frame-ancestors 'self'; upgrade-insecure-requests"
Header always set Content-Security-Policy-Report-Only "default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'"
Header always unset X-Powered-By
</IfModule>Die Report-Only-Regel ist bewusst streng. Sie zeigt dir in der Konsole jede externe Quelle, die deine Website nutzt. Aus dieser Liste baust du später die echte Richtlinie. Bei nginx sieht eine Zeile so aus: add_header X-Content-Type-Options "nosniff" always;
Welche Fehler passieren beim Setzen von Sicherheitsheadern häufig?
- Header doppelt gesetzt: Hoster, Plugin und
.htaccesssenden denselben Header mit unterschiedlichen Werten. Lege dich auf einen Ort fest. - HSTS sofort mit einem Jahr und preload: Ein späteres Zertifikatsproblem lässt sich dann nicht schnell beheben.
- CSP direkt scharf geschaltet: Schriften, Videos oder der Consent-Banner fallen aus, oft erst auf einzelnen Unterseiten.
- Nur per PHP gesetzt: Zwischengespeicherte Seiten liefern die Header nicht aus.
- Bewertung mit Sicherheit verwechselt: Eine gute Note im HTTP Observatory zeigt laut MDN, dass du die geprüften Funktionen nutzt. Sie sagt nichts über veraltete Plugins oder schwache Passwörter.
Checkliste: Sicherheitsheader setzen
- Ausgangszustand für Startseite, Beitrag und Anmeldeseite gemessen
- Ort für die Header festgelegt (bevorzugt Serverebene), Sicherungskopie der Konfiguration angelegt
X-Content-Type-Options: nosniffaktivReferrer-Policy: strict-origin-when-cross-originaktivPermissions-Policynur für ungenutzte Funktionen gesperrt- Rahmenschutz mit
SAMEORIGINbzw.frame-ancestors 'self' - HSTS in Stufen erhöht,
includeSubDomainsnur nach Subdomain-Prüfung - CSP zuerst als Report-Only, Verstöße ausgewertet
X-XSS-Protectionentfernt,X-Powered-Byentfernt- Cache geleert, Formulare, Kasse, Videos, Consent-Banner und Editor getestet
- Werte und Datum dokumentiert
Häufige Fragen
Machen Sicherheitsheader meine Website langsamer?
Nein, spürbar nicht. Es handelt sich um wenige zusätzliche Textzeilen pro Antwort. Für die Ladezeit sind Bilder, Skripte und Caching entscheidend, wie in unserem Beitrag dazu, wie du deine WordPress-Website schneller machst.
Reicht ein Sicherheits-Plugin dafür aus?
Viele Sicherheits-Plugins setzen Header per PHP. Das funktioniert, solange keine Caching-Lösung die Seiten ohne PHP ausliefert. Prüfe nach der Aktivierung deshalb immer eine zwischengespeicherte Seite in den Entwicklertools.
Verbessern Sicherheitsheader mein Google-Ranking?
Davon solltest du nicht ausgehen. Sicherheitsheader schützen in erster Linie deine Besucher. HTTPS selbst ist dagegen Pflicht, und HSTS sorgt dafür, dass Besucher auch dort bleiben.
Was mache ich, wenn nach einer neuen Regel etwas nicht mehr funktioniert?
Entferne die zuletzt geänderte Zeile, leere den Cache und prüfe erneut. Bei HSTS hilft das nicht sofort: Browser, die den Header schon gespeichert haben, halten sich bis zum Ablauf von max-age daran. Genau deshalb beginnst du mit fünf Minuten.
