Security-Header

Security-Header sind Zeilen in der Antwort Ihres Webservers, die dem Browser sagen, was er verweigern soll: Dateitypen raten, Ihre Seiten in fremden Frames anzeigen, vollständige Adressen an andere Websites weitergeben, auf HTTP zurückfallen oder Skripte von unbekannten Hosts laden. Hive setzt sie für Sie, erzeugt die passende Webserver-Konfiguration und prüft, was bei Besuchern wirklich ankommt. Diese Seite erklärt jeden Header, die drei Wege, auf denen er ankommen kann, und was zu tun ist, wenn die Prüfung ein Problem meldet.

Was in welchem Tarif enthalten ist

Alle Header-Einstellungen liegen unter Schutz-Einstellungen → Firewall & Bots → Security-Header. Der Hauptschalter Security-Header senden ist nach der Installation aus; die Empfehlung des Schnellstarts schaltet ihn ein. Die drei Basis-Header gehören zum kostenlosen Plugin. Die erweiterten Header kommen mit dem Pro-Add-on ab dem Tarif Professional und funktionieren im Local Shield wie im Community Network.

Jeder Header wird nur gesendet, solange Security-Header senden eingeschaltet ist. Endet ein Tarif, sendet Hive die erweiterten Header nicht mehr und behält die drei Basis-Header. Header, die Sie in die Webserver-Konfiguration kopiert haben, betrifft beides nicht: Der Webserver sendet sie weiter, bis Sie sie dort entfernen.

Drei Wege zum Besucher

Der Bereich So erreichen die Header Ihre Besucher über den Header-Zeilen zeigt den Zustand jedes Wegs auf Ihrer Website.

1. Webserver-Konfiguration. nginx oder Apache setzen die Header bei jeder Antwort: Seiten aus einem Seitencache, Bilder, CSS- und JavaScript-Dateien, die Anmeldeseite und Fehlerseiten. Das ist der Weg mit der größten Kompatibilität. Hive erzeugt die Konfiguration aus Ihren Einstellungen.
2. Erweiterter Schutz. Die Firewall, die vor WordPress läuft (siehe Firewall und WAF), sendet die Header ebenfalls. Sie erreicht Seiten, die ein Cache-Plugin über PHP ausliefert, etwa aus advanced-cache.php. Sie wirkt nur bei Frontend-Anfragen über index.php, nicht in wp-admin, und sendet HSTS nur über HTTPS.
3. Nur WordPress. Hive setzt die Header auf jede Frontend-Seite, die WordPress selbst erzeugt. Seiten aus einem Seitencache, statische Dateien und alles, was der Webserver selbst beantwortet, gehen ohne sie hinaus.

Wie Sie sich auch entscheiden: Setzen Sie jeden Header nur an einer Stelle. Einen Header, den der Webserver selbst setzt, sieht WordPress nicht, Hive kann ihn also nicht auslassen, und er kommt dann doppelt an. Die Header-Prüfung findet das.

Schritt für Schritt einrichten

Jeder Header im Einzelnen

So sehen die Header in einer Antwort aus:

X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Referrer-Policy: strict-origin-when-cross-origin
Strict-Transport-Security: max-age=31536000; includeSubDomains
Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=(), usb=()
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin

HSTS. Hat ein Browser den Header einmal gesehen, verbindet er sich so lange nur noch über HTTPS, wie max-age angibt, und für Besucher, die ihn schon haben, lässt sich das nicht zurücknehmen. Schalten Sie ihn erst ein, wenn jede Seite und jede Datei über HTTPS lädt. Der gespeicherte Standardwert ist 63072000 (zwei Jahre), zugleich die Obergrenze; beginnen Sie mit 300 (fünf Minuten). HSTS includeSubDomains dehnt die Regel auf jede Subdomain aus, auch auf Mail- und Shop-Subdomains. HSTS preload bittet die Browser, Ihre Domain in ihre eingebaute Liste aufzunehmen (hstspreload.org); das verlangt includeSubDomains und mindestens ein Jahr, und von der Liste herunterzukommen dauert Monate. Hive sendet HSTS nur über HTTPS. Hinter einem Proxy, der TLS beendet, muss WordPress die Anfrage als HTTPS erkennen, sonst lässt Hive HSTS weg.

Permissions-Policy. feature=() schaltet eine Funktion ab, feature=(self) erlaubt sie nur Ihren eigenen Seiten. Der Standardwert schaltet payment ab; ein Shop mit Apple-Pay- oder Google-Pay-Buttons braucht payment=(self) oder muss den Eintrag entfernen, sonst erscheinen die Buttons nicht.

X-Frame-Options und die CSP. Aktuelle Browser folgen zuerst der Direktive frame-ancestors einer erzwungenen Content-Security-Policy. X-Frame-Options bleibt für ältere Browser; halten Sie beide auf derselben Linie, etwa SAMEORIGIN und frame-ancestors 'self'.

Content-Security-Policy Schritt für Schritt

Eine CSP ist eine Liste von Quellen, aus denen der Browser Skripte, Styles, Bilder, Schriften, Frames und Verbindungen laden darf. Alles andere verweigert er. Sie ist der stärkste Header und der, der am meisten stören kann, deshalb hat sie zwei Modi: Nur Protokollierung sendet die Richtlinie als Content-Security-Policy-Report-Only, nichts wird gesperrt und jeder Verstoß erscheint in der Browser-Konsole. Erzwingen sendet Content-Security-Policy und sperrt.

1. Mit der WordPress-Startrichtlinie beginnen. Stellen Sie den Content-Security-Policy-Modus auf Nur Protokollierung und fügen Sie die Richtlinie unten in das Feld Content-Security-Policy ein. Sie passt zu einer WordPress-Website ohne externe Dienste. Die meisten Themes brauchen 'unsafe-inline' für Skripte und Styles, deshalb ist es enthalten.
2. Jede Seitenart öffnen. Startseite, ein Beitrag, eine Seite, das Kontaktformular, der Shop, der Warenkorb und die Kasse, jeweils mit akzeptiertem Cookie-Banner, denn Tracking und Einbettungen laden oft erst nach der Einwilligung. Öffnen Sie die Browser-Konsole mit F12; dort steht jede Quelle, die die Richtlinie nicht erlaubt, mit der verletzten Direktive.
3. Jede externe Quelle in ihre Direktive eintragen. Ein Skript-Host gehört in script-src, ein Host, an den die Seite Daten sendet, in connect-src, ein Video- oder Karten-Frame in frame-src, ein Schrift-Host in font-src. Direktiven trennen Sie mit Semikolon, Hosts mit Leerzeichen. Speichern, neu laden und wiederholen, bis die Konsole ruhig bleibt.
4. Auf Erzwingen umstellen. Stellen Sie den Modus auf Erzwingen, öffnen Sie die Seitenarten noch einmal und behalten Sie Formulare und Kasse einige Tage im Blick.

Die WordPress-Startrichtlinie aus dem Plugin:

default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self'; frame-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'

Beispiel: Google Tag Manager mit Google Analytics 4. Der Tag Manager lädt sein Skript von www.googletagmanager.com, und Analytics sendet seine Messdaten an zwei Google-Hostgruppen. Tragen Sie sie in script-src und connect-src ein:

default-src 'self'; script-src 'self' 'unsafe-inline' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self' https://*.google-analytics.com https://*.analytics.google.com; frame-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'

Jedes weitere Tag im Container bringt eigene Hosts mit, die die Konsole nennt. img-src erlaubt in der Startrichtlinie bereits Bilder von jedem HTTPS-Host, Tracking-Pixel brauchen dort also keinen Eintrag. Im Modus Nur Protokollierung ignorieren Browser frame-ancestors; bis Sie erzwingen, übernimmt das X-Frame-Options.

CSP-Report-URI. Optional. Eine HTTPS-Adresse, die jeden Verstoß als JSON-Bericht erhält. Hive sendet sie als report-uri und für aktuelle Browser als report-to csp-endpoint zusammen mit einem Reporting-Endpoints-Header:

Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri https://example.com/csp-report; report-to csp-endpoint
Reporting-Endpoints: csp-endpoint="https://example.com/csp-report"

Datenschutz: Jeder Bericht enthält die IP-Adresse des Besuchers und die besuchte Adresse. Ein externer Berichtsdienst verarbeitet damit personenbezogene Daten in Ihrem Auftrag, braucht einen Auftragsverarbeitungsvertrag und gehört in Ihre Datenschutzerklärung. Für die meisten Websites reicht die Browser-Konsole während der Protokollierungsphase; lassen Sie das Feld dann leer.

Die erzeugte Webserver-Konfiguration

Unter Server-Konfiguration und Header-Prüfung zeigt Hive die Konfiguration für nginx und für Apache, erzeugt aus den gespeicherten Einstellungen, jeweils mit einer Schaltfläche Kopieren. Speichern Sie nach einer Änderung zuerst. Ist Security-Header senden aus, gibt es nichts zu erzeugen: einschalten, speichern, kopieren und wieder ausschalten, sobald die Konfiguration aktiv ist. Bewahren Sie die Zeilen auf, denn nach jeder späteren Änderung brauchen Sie dieselben Schritte. Mit den drei Basis-Headern und HSTS sieht die Ausgabe so aus:

# ReportedIP Hive: security headers for nginx.
# Paste into the server { } block that serves HTTPS, then run: nginx -t && systemctl reload nginx
# A location { } block with its own add_header inherits none of these lines.
# Repeat them there, or keep them in one file and include it in both places.
# Afterwards switch off "Send security headers" in Hive, otherwise every header is sent twice.
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Strict-Transport-Security "max-age=31536000" always;

# ReportedIP Hive: security headers for Apache (.htaccess or virtual host).
# Afterwards switch off "Send security headers" in Hive, otherwise every header is sent twice.
<IfModule mod_headers.c>
	Header always set X-Content-Type-Options "nosniff"
	Header always set X-Frame-Options "SAMEORIGIN"
	Header always set Referrer-Policy "strict-origin-when-cross-origin"
	Header always set Strict-Transport-Security "max-age=31536000" "expr=%{HTTPS} == 'on'"
</IfModule>

Worauf Sie achten sollten:

• always. Ohne diesen Zusatz setzt nginx Header nur bei erfolgreichen Antworten. Mit ihm erreichen sie auch Fehlerseiten und Weiterleitungen.
• location-Blöcke erben nicht. nginx reicht add_header-Zeilen nur an Blöcke weiter, die selbst keine haben. Ein location-Block mit eigenem Header, typischerweise Cache-Control für Bilder oder die Cache-location von Rocket-Nginx, verliert alle Security-Header. Legen Sie die Zeilen in eine Datei und binden Sie diese im server-Block und in jedem solchen location-Block ein.
• HTTPS-server-Block. Die nginx-Zeilen gehören in den Block, der Port 443 ausliefert. Ein Block, der nur von HTTP auf HTTPS umleitet, braucht sie nicht.
• Vor dem Neuladen testen. nginx -t prüft die Syntax; laden Sie erst neu, wenn der Test erfolgreich ist.
• IfModule bei Apache. Fehlt mod_headers, überspringt Apache den Block, statt jede Anfrage mit einem Fehler 500 zu beantworten. Die Prüfung zeigt die Header dann als fehlend, und der Hoster muss das Modul aktivieren.
• HSTS bei Apache. Die Bedingung expr=%{HTTPS} == 'on' beschränkt HSTS auf HTTPS, dieselben Zeilen funktionieren also auch in einer .htaccess, die beide Protokolle bedient.
• Danach „Security-Header senden“ ausschalten. Sonst setzt WordPress jeden Header auf den Seiten, die es erzeugt, ein zweites Mal.

Die Include-Datei für nginx als Beispiel:

# /etc/nginx/snippets/security-headers.conf holds the generated add_header lines
server {
    listen 443 ssl;
    server_name example.com;
    include snippets/security-headers.conf;

    location ~* \.(css|js|jpg|jpeg|png|webp|svg|woff2)$ {
        add_header Cache-Control "public, max-age=2592000";
        include snippets/security-headers.conf;
    }
}

Die Header-Prüfung

Header der Startseite prüfen lädt die Startseite Ihrer Website dreimal vom Server selbst aus: zweimal wie ein Besucher, damit die zweite Anfrage von einem vorhandenen Seitencache beantwortet wird, und einmal mit einem zusätzlichen Parameter, der am Cache vorbeigeht. Danach vergleicht sie, was ankommt, mit Ihren Einstellungen. Angefragt wird nur Ihre eigene Adresse; an reportedip.com geht nichts. Die Prüfung deckt die Startseite ab; für andere Seiten, Dateien oder die Anmeldeseite nutzen Sie den Netzwerk-Reiter der Browser-Werkzeuge, curl -sI https://example.com/ oder das kostenlose Tool Security Headers.

Statt der Tabelle können zwei weitere Meldungen erscheinen:

• „Auf der Startseite kommt kein Security-Header an, weder von WordPress noch vom Webserver.“ Nirgends ist etwas gesetzt. Schalten Sie Security-Header senden ein und speichern Sie, oder prüfen Sie, ob Ihre Server-Konfiguration aktiv ist.
• „Die Startseite konnte nicht geladen werden“ mit einer Fehlermeldung. Der Server erreicht seine eigene Adresse nicht: ein Passwortschutz auf einer Staging-Website, eine Hosting-Firewall, die Anfragen des Servers an sich selbst sperrt, oder eine Domain, die woandershin zeigt. Prüfen Sie die Header dann von außen mit den oben genannten Werkzeugen.

Die Systembereitschaft unter Systemstatus meldet den Vorschlag Gecachten Seiten fehlen die Security-Header, wenn die Header an sind, ein Seitencache aktiv ist und der Erweiterte Schutz nicht läuft. Er verschwindet, sobald der Erweiterte Schutz läuft. Nutzen Sie die Webserver-Konfiguration und haben Security-Header senden ausgeschaltet, erscheint er nicht.

Fehlersuche

Zuletzt aktualisiert: 29. Oktober 2026 · Betreut vom ReportedIP-Team