Fehlende Security-Header in WordPress hinzufügen

Security-Header sind HTTP-Response-Header, die Browser anweisen, eingebaute Sicherheitsfunktionen zu aktivieren. Den meisten WordPress-Seiten fehlen standardmaessig mehrere dieser Header, weil weder der WordPress-Core noch die meisten Hosting-Anbieter sie automatisch setzen. Die gute Nachricht: das Hinzufuegen dauert nur wenige Minuten, und die Sicherheitsverbesserung ist erheblich. Diese Anleitung behandelt jeden wichtigen Security-Header, erklaert, was jeder einzelne bewirkt, und zeigt dir, wie du sie alle auf einmal hinzufuegst.

Welche Security-Header sollte jede WordPress-Seite haben?

Hier ist die vollstaendige Liste der empfohlenen Security-Header mit ihren Werten und wogegen sie schuetzen:

• X-Frame-Options: SAMEORIGIN: verhindert, dass deine Seite in einem Iframe auf einer anderen Domain geladen wird. Das stoppt Clickjacking-Angriffe, bei denen eine boesartige Seite unsichtbare Buttons ueber deine Seite legt.
• X-Content-Type-Options: nosniff: hindert Browser daran, den MIME-Typ einer Datei zu erraten. Ohne diesen Header koennte ein Angreifer eine Datei hochladen, die wie ein Bild aussieht, aber JavaScript enthaelt, und der Browser koennte sie ausfuehren.
• Referrer-Policy: strict-origin-when-cross-origin: kontrolliert, wie viel URL-Information geteilt wird, wenn Nutzer auf Links zu anderen Seiten klicken. Diese Einstellung sendet die vollstaendige URL fuer Same-Origin-Anfragen, aber nur die Domain fuer Cross-Origin-Anfragen, und schuetzt damit sensible URL-Parameter.
• Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(): deaktiviert Browser-Funktionen, die deine Seite nicht nutzt. Die leeren Klammern bedeuten "niemand darf diese Funktion nutzen," was verhindert, dass boesartige Skripte auf Kamera, Mikrofon oder Standort zugreifen.
• Strict-Transport-Security: max-age=31536000; includeSubDomains: zwingt Browser, immer HTTPS zu verwenden. Siehe unsere dedizierte HSTS-Anleitung fuer Details zum sicheren Rollout.
• X-XSS-Protection: 1; mode=block: ein Legacy-Header fuer aeltere Browser, der den eingebauten XSS-Filter aktiviert. Moderne Browser haben dies zugunsten von CSP als veraltet markiert, aber es schadet nicht, ihn fuer Abwaertskompatibilitaet einzuschliessen.
• Content-Security-Policy: der maechtigste (und komplexeste) Security-Header. Siehe unsere dedizierte CSP-Anleitung fuer eine vollstaendige Schritt-fuer-Schritt-Erklaerung.

Wie du priorisierst: Welche Header zuerst hinzufuegen

Wenn du zum ersten Mal Security-Header hinzufuegst, hier ist die Reihenfolge, die dir die groesste Sicherheitsverbesserung bei geringstem Risiko bringt:

1. X-Content-Type-Options: null Risiko, irgendetwas kaputtzumachen. Einfach hinzufuegen.
2. X-Frame-Options: sicher, es sei denn, du bettest deine Seite absichtlich in Iframes auf anderen Domains ein (bei den meisten WordPress-Seiten unwahrscheinlich).
3. Referrer-Policy: sehr geringes Risiko. Der empfohlene Wert strict-origin-when-cross-origin ist bereits das Standardverhalten moderner Browser.
4. Permissions-Policy: geringes Risiko, es sei denn, deine Seite nutzt tatsaechlich die Kamera-, Mikrofon- oder Geolocation-APIs.
5. X-XSS-Protection: Legacy-Header, ueberhaupt kein Risiko.
6. Strict-Transport-Security: erfordert zuerst funktionierendes HTTPS. Folge einem schrittweisen Rollout (siehe unsere HSTS-Anleitung).
7. Content-Security-Policy: hoechstes Risiko, Dinge bei WordPress kaputtzumachen. Starte immer mit dem Report-Only-Modus (siehe unsere CSP-Anleitung).

Alle Header ueber Apache .htaccess hinzufuegen

Dies ist die gaengigste Methode fuer WordPress-Seiten auf Shared Hosting. Oeffne die .htaccess-Datei in deinem WordPress-Stammverzeichnis und fuege den folgenden Block hinzu. Platziere ihn vor dem Abschnitt # BEGIN WordPress, um alles uebersichtlich zu halten:

<IfModule mod_headers.c>
    # Clickjacking verhindern
    Header always set X-Frame-Options "SAMEORIGIN"

    # MIME-Type-Sniffing verhindern
    Header always set X-Content-Type-Options "nosniff"

    # Referrer-Informationen kontrollieren
    Header always set Referrer-Policy "strict-origin-when-cross-origin"

    # Browser-Funktionen einschraenken
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()"

    # HTTPS erzwingen (nur hinzufuegen, wenn SSL vollstaendig funktioniert)
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

    # XSS-Schutz fuer Legacy-Browser
    Header always set X-XSS-Protection "1; mode=block"
</IfModule>

Ein paar Dinge, die du beachten solltest:

• Der IfModule-Wrapper stellt sicher, dass Apache keinen 500-Fehler ausgibt, wenn mod_headers auf deinem Server nicht aktiviert ist.
• Die Verwendung von Header always set (statt nur Header set) stellt sicher, dass die Header bei allen Antworten gesendet werden, einschliesslich Fehlerseiten.
• Wenn du bereits einen <IfModule mod_headers.c>-Block in deiner .htaccess hast, fuege die einzelnen Header-Zeilen in diesen bestehenden Block ein, anstatt einen doppelten zu erstellen.

Alle Header ueber Nginx hinzufuegen

Wenn deine WordPress-Seite auf Nginx laeuft (verbreitet bei Managed-WordPress-Hostern wie Kinsta, Cloudways, GridPane oder SpinupWP), fuege diese Zeilen in deinen server-Block ein:

# Security Headers
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-XSS-Protection "1; mode=block" always;

Wichtige Nginx-spezifische Hinweise:

• Das Schluesselwort always sendet den Header bei allen Antwortcodes (einschliesslich 4xx und 5xx). Ohne es sendet Nginx Header nur bei 2xx-Antworten.
• Wenn du einen separaten location-Block hast, der PHP verarbeitet (z.B. location ~ .php$), musst du die Header moeglicherweise auch dort hinzufuegen, je nach deiner Nginx-Konfiguration. Nginx vererbt add_header-Direktiven nicht von uebergeordneten Bloecken, wenn der untergeordnete Block eigene add_header-Eintraege hat.
• Nach Aenderungen immer testen und neu laden: sudo nginx -t && sudo systemctl reload nginx.

Header ueber PHP in WordPress hinzufuegen

Wenn du keinen Zugriff auf Server-Konfigurationsdateien hast, kannst du Security-Header per PHP senden. Fuege dies in die functions.php deines Themes oder in ein benutzerdefiniertes seitenspezifisches Plugin ein:

function iwp_add_security_headers() {
    if ( is_admin() ) {
        return;
    }

    header( 'X-Frame-Options: SAMEORIGIN' );
    header( 'X-Content-Type-Options: nosniff' );
    header( 'Referrer-Policy: strict-origin-when-cross-origin' );
    header( 'Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()' );
    header( 'X-XSS-Protection: 1; mode=block' );
}
add_action( 'send_headers', 'iwp_add_security_headers' );

Die is_admin()-Pruefung ueberspringt den WordPress-Adminbereich, um moegliche Konflikte mit der Admin-Funktionalitaet zu vermeiden. Beachte, dass dieser PHP-Ansatz eine Einschraenkung hat: er gilt nur fuer Seiten, die WordPress verarbeitet. Statische Dateien (Bilder, CSS, JS, Fonts), die direkt von deinem Webserver ausgeliefert werden, tragen diese Header nicht. Fuer vollstaendige Abdeckung ist die serverseitige Konfiguration immer die bessere Wahl.

WordPress Security-Header-Plugins

Wenn du einen plugin-basierten Ansatz bevorzugst, bieten diese Optionen eine benutzerfreundliche Oberflaeche zur Verwaltung von Security-Headern:

• HTTP Headers: ein kostenloses Plugin mit einer umfassenden Oberflaeche zum Setzen aller Security-Header. Es unterstuetzt X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy und mehr. Du konfigurierst alles ueber den WordPress-Admin, ohne Dateien zu beruehren.
• Really Simple SSL Pro: die Premium-Version enthaelt ein Security-Header-Modul, mit dem du einzelne Header ein- oder ausschalten kannst. Es bietet auch Empfehlungen und erklaert jeden Header.
• Headers Security Advanced & HSTS WP: ein fokussiertes Plugin speziell fuer Security-Header. Es deckt alle wichtigen Header ab und bietet Vorlagen fuer gaengige Konfigurationen.

Obwohl Plugins praktisch sind, haben sie Kompromisse. Wenn das Plugin deaktiviert, mit einem Bug aktualisiert oder entfernt wird, verschwinden deine Security-Header sofort. Fuer Produktionsseiten ist die serverseitige Konfiguration zuverlaessiger, weil sie nicht davon abhaengt, dass WordPress oder ein Plugin aktiv ist.

Header mit Online-Tools testen

Nachdem du deine Header hinzugefuegt hast, ueberpruefen sie mit diesen kostenlosen Tools:

• securityheaders.com: gib deine URL ein und erhalte eine Bewertung von A+ bis F zusammen mit einer detaillierten Aufschluesselung, welche Header vorhanden sind und welche fehlen. Strebe mindestens eine A-Bewertung an.
• observatory.mozilla.org: Mozillas Tool fuehrt eine umfassendere Analyse durch, einschliesslich CSP-Bewertung und Cookie-Sicherheit.
• Browser-DevTools: druecke F12, gehe zum Netzwerk-Tab, klicke auf die Hauptdokument-Anfrage und scrolle zu Antwort-Header, um zu sehen, was dein Server genau sendet.

Du kannst auch ueber die Kommandozeile pruefen:

curl -sI https://example.com

Dies zeigt alle Response-Header, einschliesslich deiner neu hinzugefuegten Security-Header.

CDN- und Reverse-Proxy-Ueberlegungen

Wenn deine WordPress-Seite hinter einem CDN wie Cloudflare, Sucuri oder Fastly sitzt, beachte, dass das CDN Header entfernen, ueberschreiben oder eigene hinzufuegen kann. Hier ist, was du wissen musst:

• Cloudflare: entfernt Security-Header standardmaessig nicht, sodass Header, die auf deinem Origin-Server gesetzt sind, durchgeleitet werden. Cloudflare bietet auch eigene Security-Header-Einstellungen im Dashboard unter SSL/TLS > Edge Certificates (fuer HSTS) und in verwalteten Regeln.
• Sucuri: deren Firewall kann automatisch einige Security-Header hinzufuegen. Pruefe deine Sucuri-Dashboard-Einstellungen, um zu sehen, welche aktiv sind, und vermeide Duplikate.
• Fastly / KeyCDN / BunnyCDN: die meisten CDNs erlauben dir, benutzerdefinierte Response-Header in ihrem Konfigurationspanel hinzuzufuegen. Dies kann eine gute Alternative sein, wenn du die Server-Konfiguration auf deinem Origin nicht aendern kannst.

Wenn du doppelte Header in deiner Antwort siehst (z.B. zwei X-Frame-Options-Zeilen), kann dies zu unvorhersehbarem Browser-Verhalten fuehren. Stelle sicher, dass jeder Header nur an einer Stelle gesetzt wird: entweder auf deinem Origin-Server oder auf CDN-Ebene, nicht beides.

Haeufige Fehler beim Hinzufuegen von Security-Headern

• Doppelte IfModule-Bloecke: wenn deine .htaccess bereits einen <IfModule mod_headers.c>-Block hat (vielleicht von einem Plugin), kann das Hinzufuegen eines zweiten Konflikte verursachen. Fuege deine Header in den bestehenden Block ein.
• Header nur per PHP setzen: dies uebersieht alle statischen Dateien. Verwende serverseitige Konfiguration fuer vollstaendige Abdeckung.
• Header in Location-Bloecken ueberschreiben (Nginx): wenn ein untergeordneter location-Block irgendein add_header hat, ersetzt es alle Header des uebergeordneten Blocks. Du musst alle Header in jedem Location-Block wiederholen, der eigene definiert.
• Nach Plugin-Updates nicht testen: ein Plugin-Update oder Theme-Wechsel kann deine PHP-basierten Header entfernen. Teste immer nach groesseren Aenderungen erneut.
• Subdomains vergessen: wenn du Subdomains hast (Staging, Mail, etc.), stelle sicher, dass diese ebenfalls Security-Header konfiguriert haben. Angreifer zielen oft auf die schwaechste Subdomain.

Security-Header mit InspectWP ueberpruefen

Nachdem du alle Header hinzugefuegt hast, fuehre einen neuen InspectWP-Scan deiner WordPress-Seite durch. Der Sicherheitsbereich deines Reports listet jeden Security-Header auf und zeigt seinen Status an. Jeder Header, der vorhanden und korrekt konfiguriert ist, erscheint gruen. Fehlende Header werden je nach Wichtigkeit rot oder gelb angezeigt. Nutze die automatische Report-Funktion von InspectWP, um deine Header ueber die Zeit zu ueberwachen und Regressionen zu erkennen, die durch Serveraenderungen oder Plugin-Updates verursacht werden.