🔒 HTTP-Sicherheitsheader für WordPress: vollständige Einrichtungsanleitung

Ihre WordPress-Website läuft, das Sicherheits-Plugin ist installiert, aber ein Check auf securityheaders.com bescheinigt Ihnen ein F. Kommt Ihnen das bekannt vor?

HTTP-Sicherheitsheader sind eine unsichtbare Schutzschicht, die selbst nach der Einrichtung einer Firewall und Zwei-Faktor-Authentifizierung oft übersehen wird. Sie benötigen keine Lizenzverlängerungen, belasten den Server nicht und blockieren ganze Angriffsklassen: von Clickjacking bis Session-Hijacking. Und sie lassen sich in 10 Minuten einrichten.

Im Folgenden Schritt für Schritt: welche Header Sie tatsächlich brauchen, wie Sie sie per.htaccess, functions.php oder Plugin konfigurieren und wie Sie prüfen, dass der Schutz nicht nur auf dem Papier steht, sondern funktioniert.

💡 Kurzüberblick:

• Prüfen Sie die aktuellen Header Ihrer Website über securityheaders.com oder Mozilla Observatory, um das reale Bild zu sehen
• Aktivieren Sie einen Basissatz von 4 bis 5 Headern: X-Content-Type-Options, X-Frame-Options, HSTS, Referrer-Policy, Permissions-Policy
• Wählen Sie Ihren Weg: ein paar Zeilen in der.htaccess (Apache/LiteSpeed), ein Snippet in der functions.php oder das Plugin Headers Security Advanced & HSTS WP
• CSP heben Sie sich für später auf: Die Konfiguration ist knifflig und legt Gutenberg lahm, wenn sie ohne Tests erfolgt
• Prüfen Sie nach der Umsetzung erneut: Ein A+ ist in 10 Minuten erreichbar

Was HTTP-Sicherheitsheader sind

Wenn ein Browser eine Seite anfordert, sendet der Webserver mehr als nur HTML-Code zurück. Jede HTTP-Antwort enthält Servicefelder, die Header. Einige steuern Caching und Inhaltstyp, andere die Sicherheit.

Der Browser liest Sicherheitsheader, bevor er überhaupt mit dem Rendern der Seite beginnt. Wenn der Server sagt: „Ich verbiete die Einbettung dieser Seite in Frames", wird der Browser das nicht tun, selbst wenn der Seitencode ein <iframe> enthält. Wenn der Server sagt: „Verwende ein Jahr lang nur HTTPS", merkt sich der Browser das und ruft die HTTP-Version nicht auf, selbst wenn der Nutzer sie manuell eintippt.

Kein JavaScript, kein Plugin, keine Firewall beeinflusst das. Das ist die Protokollebene. Genau deshalb sind Header eine separate, unabhängige Verteidigungslinie.

Warum eine WordPress-Website das braucht

Sicherheits-Plugins wie Wordfence oder Solid Security schließen Schwachstellen auf Anwendungsebene: Brute-Force, Injections, schädliche Uploads. HTTP-Header arbeiten eine Ebene höher: Sie schützen den Kommunikationskanal selbst zwischen Server und Besucher.

Folgendes blockieren korrekt konfigurierte Header:

• Clickjacking. Ein Angreifer bettet Ihre Website in einen transparenten Frame über seiner eigenen ein und fängt Nutzerklicks ab. Blockiert durch den X-Frame-Options-Header oder die frame-ancestors-Direktive in CSP.

• MIME-Sniffing. Der Browser versucht, den Dateityp zu „erraten" und führt möglicherweise ein hochgeladenes Bild als JavaScript aus. Blockiert durch X-Content-Type-Options: nosniff.

• Session-Hijacking. Ein Angreifer in einem offenen WLAN verändert die Serverantwort und stiehlt Login-Cookies. HSTS verbietet dem Browser den Zugriff auf die HTTP-Version der Website.

• Referrer-Leakage. Beim Folgen eines externen Links sieht die Zielseite, von welcher Seite der Nutzer kam, inklusive der URL mit Parametern. Referrer-Policy schränkt das ein.

• Unbefugter Gerätezugriff. Eine Webseite fordert ohne Wissen des Nutzers Mikrofon, Kamera oder Standort an. Permissions-Policy blockiert solche Anfragen auf Browserebene.

CSP fügt eine weitere Schicht hinzu: Sie legen explizit fest, welche Domains Skripte, Styles und Schriften laden dürfen. Selbst wenn schädlicher Code in die Datenbank gelangt, führt der Browser ihn nicht aus, weil die Quelle nicht in der Freigabeliste steht. CSP erfordert jedoch Sorgfalt: Ein kleiner Fehler, und der Gutenberg-Editor funktioniert nicht mehr.

Wichtige HTTP-Sicherheitsheader: Was sie umfassen und warum

Nachfolgend die Header, die sich für jede WordPress-Website zu konfigurieren lohnen. Zu jedem nennen wir: gegen welchen Angriff er schützt, den empfohlenen Wert und wo es zu Problemen kommen kann.

X-Content-Type-Options

Der einfachste und sicherste einzurichtende Header. Der einzig gültige Wert ist nosniff. Der Browser rät dann nicht mehr den MIME-Typ einer Datei anhand ihres Inhalts, sondern vertraut ausschließlich dem Typ, den der Server im Content-Type-Header gesendet hat.

Ohne diesen Header kann der Browser ein vom Nutzer hochgeladenes Bild als Skript interpretieren und ausführen, ein klassisches Szenario eines Datei-Upload-Angriffs.

Empfohlener Wert: nosniff

Risiko von Fehlfunktionen: minimal. Probleme sind nur möglich, wenn der Server Dateien mit einem falschen Content-Type ausliefert, aber das ist ein separates Problem, das man beheben sollte, statt es zu kaschieren.

X-Frame-Options

Steuert, ob Ihre Website in einem <frame>, <iframe> oder <object> auf einer anderen Seite eingebettet werden darf.

Zwei Hauptwerte:

• DENY, ein vollständiges Einbettungsverbot. Maximaler Schutz.
• SAMEORIGIN, Einbettung nur von der eigenen Domain aus erlaubt. Notwendig, wenn Sie selbst Frames für Ihre eigenen Seiten nutzen (zum Beispiel Vorschau im Admin-Bereich).

Für die meisten WordPress-Seiten funktioniert SAMEORIGIN. Wenn Sie sicher wissen, dass keine Frames verwendet werden, setzen Sie DENY.

Empfohlener Wert: SAMEORIGIN

Risiko von Fehlfunktionen: manche Plugins nutzen iframes für Vorschauen. Falls nach dem Aktivieren von DENY etwas im Admin-Bereich nicht mehr angezeigt wird, wechseln Sie zu SAMEORIGIN.

Strict-Transport-Security (HSTS)

Weist den Browser an: „Greife für die nächsten N Sekunden nur per HTTPS auf diese Domain zu." Schützt vor Downgrade-Angriffen und Cookie-Diebstahl in offenen Netzwerken.

Der entscheidende Parameter ist max-age. Es empfiehlt sich, mit einem kleinen Wert zu beginnen (ein Tag oder eine Woche) und diesen nach Prüfung auf ein Jahr zu erhöhen.

Der optionale Parameter includeSubDomains erweitert die Regel auf alle Subdomains, wichtig, wenn Sie mehrere haben und ein CDN nutzen.

Der Parameter preload trägt die Seite in die globale HSTS-Liste der Browser ein: Chrome, Firefox und Safari greifen dann bereits vor der ersten Anfrage nur noch per HTTPS auf Ihre Domain zu. Die Anmeldung erfolgt über hstspreload.org.

Empfohlener Wert: max-age=31536000; includeSubDomains

Risiko von Fehlfunktionen: wenn Sie HSTS aktivieren und das SSL-Zertifikat abläuft, können Nutzer überhaupt nicht mehr auf die Seite zugreifen. Achten Sie auf die automatische Zertifikatserneuerung.

Referrer-Policy

Verwaltet, welche Informationen über die Ursprungsseite der Browser beim Folgen eines Links an eine andere Website sendet.

Wichtigste Werte, vom strengsten zum freizügigsten:

• no-referrer, es wird gar nichts gesendet.
• strict-origin-when-cross-origin, an eine andere Domain wird nur die Domain gesendet (kein Pfad oder Parameter); an die eigene die vollständige URL. Die optimale Balance aus Privatsphäre und Analyse.
• strict-origin, immer nur die Domain, kein Pfad.

Wenn Sie nicht möchten, dass Zielseiten erfahren, woher der Nutzer kam, setzen Sie no-referrer. Bedenken Sie aber: Sie verlieren dann Referral-Traffic in Ihrer eigenen Analyse.

Empfohlener Wert: strict-origin-when-cross-origin

Risiko von Fehlfunktionen: minimal. Manche Drittanbieterdienste benötigen einen Referrer, um zu funktionieren (zum Beispiel Zahlungsgateways mit Herkunftsprüfung). Solche Fälle lassen sich über die Browser-Konsole nachverfolgen.

Permissions-Policy

Früher Feature-Policy genannt. Beschränkt den Zugriff der Webseite auf „Hardware"-Browser-APIs: Mikrofon, Kamera, Geolokalisierung, USB, Payment-APIs und so weiter.

Format: название-фичи=(разрешённый-источник). Zum Beispiel:

1
Permissions-Policy: camera=(), microphone=(), geolocation=(self)

Dieses Beispiel blockiert den Zugriff auf Kamera und Mikrofon für alle Quellen vollständig und erlaubt Geolokalisierung nur für die eigene Seite (self).

Vollständige Liste der Funktionen auf MDN. Für eine WordPress-Seite ohne Videochats und PWA-Funktionen reicht es, Kamera, Mikrofon und Geolokalisierung zu blockieren; der Rest ist optional.

Empfohlener Wert: hängt von der Funktionalität der Seite ab. Minimum: camera=(), microphone=(), geolocation=(self).

Risiko von Fehlfunktionen: wenn die Seite Videoanrufe, PWA- oder WebUSB-Funktionen nutzt, prüfen Sie, welche Funktionen sie benötigt, und blockieren Sie diese nicht.

Content-Security-Policy (CSP)

Der mächtigste und zugleich gefährlichste einzurichtende Header. Definiert eine Positivliste von Quellen für Skripte, Styles, Schriften, Bilder, Frames und andere Ressourcen.

Beispiel einer minimalen Richtlinie für WordPress:

1
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;
2

Warum unsafe-inline und unsafe-eval: WordPress, Gutenberg und Dutzende Plugins erzeugen Inline-Skripte und verwenden eval(). Ohne diese Direktiven funktioniert der Admin-Bereich schlicht nicht. Das ist der Preis der Kompatibilität.

Empfehlung: aktivieren Sie CSP nicht als Erstes. Konfigurieren Sie zuerst die anderen 5 Header. Implementieren Sie CSP nur, wenn Sie Ressourcen für Tests und Monitoring haben; beginnen Sie mit dem Content-Security-Policy-Report-Only-Modus und sammeln Sie ein paar Wochen lang Verstoßprotokolle, bevor Sie in den Durchsetzungsmodus wechseln.

Risiko von Fehlfunktionen: hoch. Ein Fehler in der CSP kann Frontend und Admin-Bereich vollständig lahmlegen. Testen Sie immer auf einer Staging-Umgebung oder per Report-Only.

So prüfen Sie die aktuellen Header Ihrer Website

Vor der Konfiguration steht das Audit. Drei Werkzeuge, von einfach bis detailliert:

• securityheaders.com, URL eingeben und eine Bewertung von A+ bis F mit Aufschlüsselung pro Header erhalten. Kostenlos, keine Registrierung.

• Mozilla Observatory, ein detaillierteres Audit: bewertet nicht nur Header, sondern auch TLS-Einstellungen, Cookie-Attribute, CORS und weitere Aspekte. Ebenfalls kostenlos.

• Chrome DevTools, öffnen Sie den Network-Tab, wählen Sie eine beliebige Anfrage an Ihre Seite aus und sehen Sie im Abschnitt Response Headers nach. Ein schneller Weg, um zu prüfen, ob Änderungen nach der Bearbeitung der.htaccess „greifen".

Prüfen Sie Ihre Seite jetzt. Liegt die Bewertung unter B, haben Sie nicht einmal grundlegende Header, und ein Drittel der folgenden Punkte richten Sie in 5 Minuten ein.

Wege zur Konfiguration von HTTP-Headern in WordPress

Drei Wege, von manuell bis automatisch. Wählen Sie je nach Ihrer Situation.

Methode 1: Über.htaccess (Apache/LiteSpeed)

Der schnellste Weg für Websites auf Apache oder LiteSpeed. Ergänzen Sie die .htaccess-Datei im Wurzelverzeichnis der Website (vor # BEGIN WordPress):

1
<IfModule mod_headers.c>
2
    Header set X-Content-Type-Options "nosniff"
3
    Header set X-Frame-Options "SAMEORIGIN"
4
    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
5
    Header set Referrer-Policy "strict-origin-when-cross-origin"
6
    Header set Permissions-Policy "camera=(), microphone=(), geolocation=(self)"
7
</IfModule>

Der <IfModule mod_headers.c>-Wrapper stellt sicher, dass die Website nicht mit einem 500-Fehler abstürzt, falls das Modul mod_headers nicht aktiviert ist. Wenn Sie sicher wissen, dass es aktiv ist, können Sie ihn weglassen.

Führen Sie nach dem Speichern im Terminal (falls Sie WP-CLI haben) den Befehl aus oder öffnen Sie einfach die Website und prüfen Sie die Header über securityheaders.com. Änderungen in .htaccess greifen sofort; ein Server-Neustart ist nicht nötig.

Methode 2: Über functions.php (Nginx / universell)

Funktioniert unabhängig vom Webserver, geeignet für Nginx und Apache. Ergänzen Sie die functions.php Ihres Child-Themes oder nutzen Sie das Plugin Code Snippets:

1
function sdstudio_add_security_headers() {
2
    header( 'X-Content-Type-Options: nosniff' );
3
    header( 'X-Frame-Options: SAMEORIGIN' );
4
    header( 'Strict-Transport-Security: max-age=31536000; includeSubDomains' );
5
    header( 'Referrer-Policy: strict-origin-when-cross-origin' );
6
    header( 'Permissions-Policy: camera=(), microphone=(), geolocation=(self)' );
7
}
8
add_action( 'send_headers', 'sdstudio_add_security_headers' );

Der Hook send_headers wird ausgelöst, bevor WordPress mit dem Senden von Inhalten beginnt, sodass die Header in der allerersten Server-Antwort ausgegeben werden.

Für Nginx ist diese Methode dem Eingriff in die Serverkonfiguration vorzuziehen (insbesondere bei Shared Hosting, wo der Zugriff auf nginx.conf oft nicht verfügbar ist). Der Nachteil: Header funktionieren nur für PHP-Anfragen, die über WordPress laufen. Statische Dateien (Bilder, CSS, JS) werden direkt von Nginx ausgeliefert und erhalten die Header nicht. Diese erfordern eine Konfiguration auf Serverebene.

Methode 3: Über das Plugin Headers Security Advanced & HSTS WP

Wenn Sie keinen Code anfassen möchten, nutzen Sie ein dediziertes Plugin. Headers Security Advanced & HSTS WP fasst alle Sicherheitsheader in einer Oberfläche zusammen und aktiviert sie mit einem einzigen Klick.

Das Plugin setzt direkt nach der Aktivierung voreingestellte Werte für alle wichtigen Header: X-Content-Type-Options, X-Frame-Options, HSTS, CSP, Referrer-Policy, Permissions-Policy und mehrere zusätzliche (CORP, COOP, COEP). Jeder Header kann deaktiviert oder an Ihre Bedürfnisse angepasst werden.

Der Vorteil dieses Ansatzes: Das Plugin ist unabhängig vom Webserver und funktioniert identisch auf Apache, Nginx, LiteSpeed und IIS. Bei der Deaktivierung versetzt es die Website-Konfiguration in den ursprünglichen Zustand zurück.

Alternative: Redirection

Das Plugin Redirection ist als Weiterleitungsmanager bekannt, kann aber auch HTTP-Header hinzufügen. Gehen Sie nach der Installation und Grundeinrichtung zum Bereich Site → Headers; die Oberfläche erlaubt es Ihnen, beliebige Paare aus „Header: Wert" anzugeben.

Diese Option bietet sich an, wenn Sie Redirection bereits für die Linkverwaltung installiert haben und kein weiteres Plugin hinzufügen möchten. Ein dediziertes Header-Plugin gibt Ihnen jedoch mehr Kontrolle und voreingestellte Werte.

Im Video eine visuelle Demonstration der Header-Konfiguration über das Plugin Headers Security Advanced: von der Installation bis zur Überprüfung des Ergebnisses auf securityheaders.com.

⁉️🤔 Häufige Fragen

Was tun, wenn die Website nach dem Aktivieren der Header nicht mehr funktioniert?

Prüfen Sie zuerst den Content-Security-Policy-Header: Er verursacht die allermeisten Ausfälle. Deaktivieren Sie CSP (oder schalten Sie ihn in den Report-Only-Modus) und prüfen Sie die Website erneut. Ein 500-Fehler nach dem Bearbeiten der.htaccess: Prüfen Sie die Syntax auf ein überflüssiges Leerzeichen, nicht geschlossene Anführungszeichen oder ein fehlendes Modul mod_headers. Benennen Sie die.htaccess per FTP um, die Website funktioniert wieder und Sie können den Fehler in Ruhe finden.

In 9 von 10 Fällen liegt das Problem spezifisch an CSP, nicht an den anderen Headern. X-Content-Type-Options, X-Frame-Options, HSTS und Referrer-Policy können die Website physisch nicht beschädigen; sie beeinflussen weder das Rendering noch die PHP-Logik. Beginnen Sie immer mit diesen.

Ist ein Plugin zwingend erforderlich oder geht das auch per Code?

Es kann und sollte per Code erfolgen, wenn Sie wissen, wie man functions.php oder.htaccess bearbeitet. Header direkt über die Serverkonfiguration zu setzen, arbeitet schneller als ein Plugin, ohne PHP-Schicht dazwischen. Ein Plugin ist jedoch bequemer für diejenigen, die keinen Code anfassen möchten, und bietet eine visuelle Oberfläche mit Voreinstellungen für jeden Header.

Auf unseren Testseiten nutzen wir beide Ansätze: auf Produktivsystemen.htaccess (weniger Fehlerquellen); auf Kundenseiten, deren Hosting die Bearbeitung der Konfiguration nicht erlaubt, das Plugin. Das Ergebnis auf securityheaders.com ist identisch: A+ in beiden Fällen.

Muss ich CSP konfigurieren, wenn die Website auf WordPress läuft?

Für die meisten Websites: nein. CSP unter WordPress erfordert unsafe-inline und unsafe-eval, damit Gutenberg und Dutzende Plugins funktionieren, was die Schutzwirkung auf ein symbolisches Maß reduziert. Ein vollwertiges CSP ist bei hochfrequentierten Projekten mit einem dedizierten Sicherheitsspezialisten sinnvoll, der jeden Verstoßbericht analysiert. Für alle anderen liefern die 5 grundlegenden Header den Löwenanteil des praktischen Schutzes.

Wie überprüfe ich, ob die Header nach der Installation funktionieren?

Öffnen Sie die Website im Browser, starten Sie die DevTools (F12) → Tab Netzwerk → klicken Sie auf die erste Anfrage an Ihre Domain → Bereich Response Headers. Wenn Sie die hinzugefügten Header sehen, funktioniert alles. Für die automatisierte Überprüfung nutzen Sie securityheaders.com: Die Seite zeigt nicht nur das Vorhandensein, sondern auch die Korrektheit der Werte sowie eine Gesamtbewertung von A+ bis F.

Was tun, wenn das Hosting die Bearbeitung der.htaccess nicht erlaubt und kein Zugriff auf functions.php besteht?

Installieren Sie Headers Security Advanced & HSTS WP über das WordPress-Admin-Panel. Das Plugin injiziert Header auf PHP-Ebene und erfordert keine Bearbeitung von Serverdateien. Dies funktioniert auf jedem Hosting, auf dem WordPress läuft, vom günstigen Shared Hosting bis zu Managed WordPress.

Beeinflussen HTTP-Header die Geschwindigkeit der Website?

Praktisch nicht. Header sind ein paar Dutzend Byte Text in der Server-Antwort. Sie führen keine Berechnungen durch, stellen keine Datenbankabfragen und belasten die CPU nicht. Die Verzögerung, die sie hinzufügen, wird in Mikrosekunden gemessen. Die einzige Ausnahme ist CSP mit einer komplexen Positivliste von Hunderten von Domains: Der Browser benötigt Zeit zum Parsen, aber selbst dann überschreitet die Auswirkung auf die Rendering-Geschwindigkeit nicht ein paar Millisekunden.

Was Sie setzen sollten und womit Sie anfangen

HTTP-Sicherheitsheader sind keine einmalige Aktion nach dem Motto „Einrichten und vergessen". Sie sind eine Basis, die standardmäßig auf jeder Website vorhanden sein sollte, wie ein SSL-Zertifikat.

Der Plan für heute:

• Prüfen Sie Ihre Website auf securityheaders.com. Wenn die Bewertung D oder F lautet, haben Sie nicht einmal X-Content-Type-Options.

• Fügen Sie die 5 grundlegenden Header hinzu, mit einer der drei oben genannten Methoden. Wenn die Website auf Apache läuft, über.htaccess (30 Sekunden). Nginx ohne Konfigurationszugriff, über functions.php (2 Minuten). Wenn Sie keinen Code anfassen möchten, das Plugin Headers Security Advanced (3 Minuten inklusive Installation).

• Prüfen Sie die Website erneut. Die Bewertung sollte auf A oder A+ steigen.

• Stellen Sie CSP zurück. Kommen Sie darauf zurück, sobald die grundlegenden Header einen Monat lang ohne Probleme gelaufen sind und Sie Zeit für Tests über Report-Only haben.

Eine Stunde, und Ihre WordPress-Website erhält eine Verteidigungsschicht, die der überwiegenden Mehrheit der Websites im Internet fehlt. Beginnen Sie jetzt gleich mit einer Prüfung.