Security-Header: Was jeder einzelne bewirkt und wie Sie ihn einrichten

Kurz gesagt: Security-Header sind Anweisungen, die Ihr Server mit jeder Seite mitschickt. Sie sorgen dafür, dass Browser immer HTTPS nutzen, Skripte nur aus freigegebenen Quellen ausführen, das Einbetten Ihrer Seiten durch andere Websites verweigern, Dateitypen nie erraten und keine vollständigen URLs im Referer-Header preisgeben. Beginnen Sie mit HTTPS überall und einem gültigen Zertifikat, und ergänzen Sie dann Strict-Transport-Security, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin sowie frame-ancestors oder X-Frame-Options. Führen Sie Content-Security-Policy zuerst im Report-Only-Modus ein. Alle Header werden in der Server- oder CDN-Konfiguration gesetzt.

Security-Header sind eine günstige Versicherung. Die meisten brauchen nur eine Zeile Serverkonfiguration, kosten keine Performance und schließen ganze Angriffsklassen aus: ein eingeschleustes Skript, das Sessions stiehlt, einen unsichtbaren Frame, der Nutzer zum Klicken verleitet, oder ein Café-WLAN, das Besucher auf unverschlüsseltes HTTP herunterstuft. Außerdem gehören sie zu den ersten Dingen, die Sicherheitsscanner, Unternehmenskunden und Sicherheitsfragebögen prüfen.

Dieser Leitfaden erklärt jeden Header und die Grundlagen der Verbindung drumherum, nennt sichere Startwerte, zeigt, wie unser kostenloser Security-Header-Checker Ihre Website testet, und führt Sie durch die Behebung jedes gemeldeten Problems.

Zuerst die Grundlagen: HTTPS, Zertifikat und Mixed Content

Header setzen auf einer verschlüsselten Verbindung auf; ohne sie helfen sie nicht. Drei Grundlagen kommen zuerst:

• HTTPS auf jeder Seite, mit Weiterleitung von HTTP. Seit Chrome 68 im Juli 2018 kennzeichnet Chrome jede HTTP-Seite als „nicht sicher“ (Chromium Blog), und Googles Leitfaden zur Seitenerfahrung fragt: „Are your pages served in a secure fashion?“
• Ein gültiges Zertifikat, das jeden genutzten Hostnamen abdeckt, einschließlich www und der Domain ohne Subdomain. Ein abgelaufenes oder nicht passendes Zertifikat löst eine ganzseitige Warnung aus.
• Kein Mixed Content. Eine sichere Seite, die Dateien über http:// lädt, ist nicht vollständig sicher. Laut MDN stellen Browser Bilder, Audio und Video automatisch auf HTTPS um und blockieren Skripte, Stylesheets, iframes und andere „blockierbare“ Inhalte komplett, wodurch die Seite kaputtgehen kann.

Die Header im Einzelnen

Strict-Transport-Security (HSTS)

HSTS weist den Browser an, für Ihren Host eine festgelegte Anzahl von Sekunden lang HTTPS zu verwenden, selbst wenn jemand http:// eintippt oder einem alten Link folgt. MDN nennt drei Punkte, die Sie kennen sollten:

• Browser ignorieren den Header, wenn er über reines HTTP ankommt. Senden Sie ihn in HTTPS-Antworten; Ihre HTTP-zu-HTTPS-Weiterleitung braucht ihn nicht.
• Er wirkt erst nach dem ersten sicheren Besuch. Preloading schließt diese Lücke.
• includeSubDomains wendet die Richtlinie auf jede Subdomain an, prüfen Sie daher vorher alle.

Die HSTS-Preload-Liste verankert Ihre Domain fest in den Browsern. Sie verlangt ein gültiges Zertifikat, eine HTTP-zu-HTTPS-Weiterleitung auf demselben Host, alle Subdomains über HTTPS und einen Header mit max-age von mindestens 31536000, includeSubDomains und preload. Sie warnt außerdem: „inclusion in the preload list cannot easily be undone“: Eine Entfernung braucht Monate, bis sie bei den Nutzern ankommt. Nutzen Sie Preload nur, wenn Sie sich sicher sind.

Content-Security-Policy (CSP)

CSP ist der stärkste Header und zugleich der schwierigste im Einsatz. Er legt fest, von wo Skripte, Styles, Bilder und andere Ressourcen geladen werden dürfen, und der Browser verweigert alles andere. MDN bezeichnet ihn hauptsächlich als „a defense against cross-site scripting (XSS) attacks.“

Die empfohlene moderne Form ist eine strikte CSP auf Basis von Nonces oder Hashes statt langer Domain-Allowlists:

Content-Security-Policy: script-src 'nonce-{RANDOM}'; object-src 'none'; base-uri 'none'

Der Nonce muss zufällig sein und bei jeder Antwort anders. MDN warnt, dass 'unsafe-inline' „defeats much of the purpose of having a CSP.“

Weil eine strikte Richtlinie Analytics-Tags, Chat-Widgets und Inline-Skripte kaputtmachen kann, führen Sie sie in zwei Schritten ein: Senden Sie Content-Security-Policy-Report-Only mit einem Reporting-Endpunkt, beheben Sie, was die Reports zeigen, und wechseln Sie dann auf den erzwingenden Header. In der CSP steckt auch upgrade-insecure-requests (ein Sicherheitsnetz gegen Mixed Content, kein Ersatz für HSTS), und dort steuert frame-ancestors das Einbetten in Frames.

X-Frame-Options und frame-ancestors

Beim Clickjacking wird Ihre Seite in einem unsichtbaren Frame auf einer anderen Website geladen, und Nutzer werden dazu gebracht, Ihre Schaltflächen anzuklicken. Zwei Wege, das zu verhindern:

• X-Frame-Options: SAMEORIGIN (oder DENY), der ältere Header. ALLOW-FROM ist veraltet und führt dazu, dass moderne Browser den Header ignorieren.
• Content-Security-Policy: frame-ancestors 'self', die flexiblere Option, die auch bestimmte Partner-Origins auflisten kann.

Beides funktioniert nicht in einem <meta>-Tag. MDN hält fest, dass X-Frame-Options in einem meta-Element „has no effect“ hat und dass frame-ancestors „is not supported in the <meta> element.“ Beachten Sie außerdem, dass frame-ancestors nicht auf default-src zurückfällt: Eine Richtlinie default-src 'none' erlaubt weiterhin jedem, die Seite einzubetten.

X-Content-Type-Options

nosniff weist Browser an, Ihrem Content-Type-Header zu vertrauen. Damit wird eine als Skript oder Stylesheet angeforderte Antwort blockiert, wenn ihr MIME-Typ nicht passt. So läuft eine als Bild getarnte hochgeladene Datei nicht als Skript. Es gibt nur einen gültigen Wert:

X-Content-Type-Options: nosniff

Stellen Sie sicher, dass Ihr Server korrekte Content-Types sendet, besonders für JavaScript und CSS, bevor Sie den Header hinzufügen.

Referrer-Policy

Wenn ein Besucher einem Link zu einer anderen Website folgt, sendet der Browser einen Referer-Header. Moderne Browser verwenden bereits standardmäßig strict-origin-when-cross-origin: Dabei wird websiteübergreifend nur der Origin (https://example.com/) gesendet, und beim Wechsel von HTTPS zu HTTP nichts (MDN). OWASP empfiehlt dennoch, ihn explizit zu setzen, „rather than relying on browser defaults.“ Vermeiden Sie unsafe-url, das überall vollständige URLs sendet, einschließlich darin enthaltener Tokens.

Permissions-Policy und die Header, die Sie entfernen sollten

Permissions-Policy schaltet Browserfunktionen ab, die Sie nicht nutzen, sodass ein eingebettetes Skript nicht nach Kamera oder Standort fragen kann. MDN stuft ihn als experimentell mit eingeschränkter Browserunterstützung ein, betrachten Sie ihn daher als zusätzliche Schicht. Unser kostenloser Checker prüft ihn nicht; der vollständige Security-Scan tut es.

Zwei Header sollten Sie entfernen statt hinzufügen: OWASP rät, X-XSS-Protection nicht zu setzen (oder auf 0 zu setzen), weil die alten Filter, die er steuerte, Schwachstellen erzeugen konnten, und bezeichnet Expect-CT als veraltet. Außerdem wird empfohlen, X-Powered-By zu entfernen und Server einen nichtssagenden Wert zu geben.

So funktioniert der Security-Header-Checker von Searvia

Der kostenlose Security-Header-Checker nutzt dieselbe Engine wie unser Website-SEO-Checker und stellt fünf Prüfungen an die Spitze. Er sendet gewöhnliche Anfragen, wie sie jeder Besucher stellen könnte; nichts wird angegriffen oder ausgespäht.

Gezählt werden Content-Security-Policy, X-Frame-Options (oder ein CSP-Header mit frame-ancestors) und X-Content-Type-Options. Referrer-Policy wird ebenfalls aufgeführt, ein Fehlen wird aber nicht negativ gewertet: Browser verwenden bereits standardmäßig strict-origin-when-cross-origin, und die Tabelle weist darauf hin. Die Ergebnistabelle zeigt den Wert jedes Headers, lange Richtlinien werden gekürzt.

Einige Grenzen, die Sie kennen sollten:

• Geprüft wird das Vorhandensein, nicht die Qualität. Eine CSP voller 'unsafe-inline' besteht hier; der vollständige Security-Scan bewertet das.
• Gelesen werden die HTTP-Response-Header. Eine CSP in einem <meta>-Tag zählt, mit einem Hinweis: frame-ancestors und Reporting funktionieren dort nicht, sie kann also X-Frame-Options nicht ersetzen. Ein Content-Security-Policy-Report-Only-Header zählt nicht als erzwungene Richtlinie.
• Geprüft wird eine Seite, nämlich die, die Sie eingeben (die Startseite, wenn Sie nur eine Domain eingeben). Andere Pfade, etwa ein Admin-Bereich oder eine API, können andere Header senden.
• Mixed Content wird nur im HTML gefunden: absolute http://-URLs in Tags. Dateien, die später von CSS oder JavaScript angefordert werden, sieht der Checker nicht.

So lesen Sie die Ergebnisse

Arbeiten Sie sich nach Priorität von oben nach unten vor. Eine fehlgeschlagene HTTPS- oder Zertifikatsprüfung ist dringend: Besucher sehen Browserwarnungen oder surfen unverschlüsselt. Aktiver Mixed Content (Skripte, iframes, Stylesheets) kommt als Nächstes, weil Browser diese Dateien blockieren und die Seite kaputtgehen kann. HSTS und die Security-Header haben im Score niedrige Priorität, lassen sich aber am schnellsten beheben, bündeln Sie sie daher in einer einzigen Konfigurationsänderung.

So beheben Sie jedes vom Checker gemeldete Problem

„The site does not work over HTTPS.“ / „HTTP does not redirect to HTTPS.“

1. Installieren Sie ein Zertifikat. Let's Encrypt ist kostenlos, und die meisten Hoster bieten es per Klick an.
2. Richten Sie eine permanente Weiterleitung von jeder http://-URL auf dieselbe https://-URL ein.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

In Cloudflare aktivieren Sie „Always Use HTTPS“ unter SSL/TLS › Edge Certificates.

„The certificate expired N days ago.“ / „The certificate does not cover this domain.“

1. Erneuern Sie es sofort und aktivieren Sie die automatische Erneuerung (Certbot sowie die meisten Hoster und CDNs tun das standardmäßig).
2. Stellen Sie sicher, dass das Zertifikat jeden ausgelieferten Hostnamen enthält, mindestens die Domain ohne Subdomain und www.
3. Schlägt die Erneuerung unbemerkt fehl, sind die üblichen Ursachen ein geänderter DNS-Eintrag, ein blockierter Validierungspfad oder ein abgelaufenes API-Token für die DNS-Validierung.

Eine Warnung mit weniger als 14 Tagen Restlaufzeit bedeutet meist, dass die automatische Erneuerung nicht funktioniert; gehen Sie dem nach, statt jedes Mal von Hand zu erneuern.

„HSTS is not set.“ / „HSTS is on but shorter than 6 months.“

Führen Sie HSTS in Stufen ein, damit eine vergessene Subdomain, die nur HTTP kann, nicht ausgesperrt wird:

1. Stellen Sie sicher, dass die Hauptseite und jede Subdomain über HTTPS funktionieren.
2. Senden Sie Strict-Transport-Security: max-age=300 einen Tag lang, dann eine Woche (604800), dann einen Monat.
3. Wechseln Sie auf max-age=31536000; includeSubDomains.
4. Erst danach ziehen Sie preload in Betracht und reichen die Domain bei hstspreload.org ein.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

„N files load over plain HTTP.“

1. Öffnen Sie die Liste der URLs im Report.
2. Ändern Sie jede auf https:// oder bei eigenen Dateien auf einen relativen Pfad. Prüfen Sie bei Dateien von Drittanbietern, ob der Anbieter HTTPS ausliefert; wenn nicht, wechseln Sie den Anbieter.
3. Durchsuchen Sie Datenbank und Theme nach fest eincodierten http://-Links; nach einer Umstellung auf HTTPS sind alte Beitragsinhalte die übliche Quelle.
4. Als Sicherheitsnetz fügen Sie Content-Security-Policy: upgrade-insecure-requests hinzu.

„N key security headers are missing.“

Fügen Sie die fehlenden in einer Änderung hinzu. Für nginx:

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 Content-Security-Policy-Report-Only "default-src 'self'; frame-ancestors 'self'; report-to csp" always;

Für Apache:

Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"

In Cloudflare fügen Sie Response-Header mit einer Transform Rule hinzu. Bei Netlify nutzen Sie eine _headers-Datei, bei Vercel die Einstellung headers in vercel.json. Beachten Sie in nginx, dass add_header in einem location-Block die auf Server-Ebene gesetzten Header ersetzt; wiederholen Sie sie also oder nutzen Sie eine Include-Datei.

Für CSP ist die Report-Only-Zeile oben ein Ausgangspunkt, keine fertige Richtlinie. Richten Sie report-to auf einen Reporting-Endpunkt, den Sie kontrollieren, werten Sie die Verstöße ein bis zwei Wochen lang aus, passen Sie die Richtlinie an und benennen Sie den Header dann in Content-Security-Policy um. Sobald sie erzwungen wird, besteht die CSP-Prüfung.

So prüfen Sie Header selbst

Der Checker zeigt, was die geprüfte Seite sendet, aber andere Seiten, Dateien und Fehlerantworten können abweichen. Zwei schnelle Möglichkeiten:

• Browser-DevTools. Öffnen Sie das Netzwerk-Panel, laden Sie die Seite neu, klicken Sie die erste Anfrage an und lesen Sie den Abschnitt Response Headers.
• Die Kommandozeile. curl -sI https://www.example.com/ gibt nur die Response-Header aus. Führen Sie es für die Startseite, eine tiefer liegende Seite, ein PDF, eine 404-Seite und Ihre Login-Seite aus.

Eine häufige Überraschung sind Header, die auf normalen Seiten erscheinen, nicht aber bei Fehlern oder Weiterleitungen. In nginx gilt add_header nur für erfolgreiche Antworten und Weiterleitungen, es sei denn, Sie ergänzen den Parameter always; deshalb enthält jedes Beispiel oben ihn. Eine weitere sind CDNs oder Hoster, die Header hinzufügen oder entfernen. Prüfen Sie also die Antwort, die die Öffentlichkeit sieht, nicht nur Ihre Serverkonfigurationsdatei.

Bedenken Sie, dass jeder Header etwas anderes schützt. Eine perfekte CSP nützt nichts gegen ein abgelaufenes Zertifikat, und HSTS nützt nichts gegen ein eingeschleustes Skript. Ziel ist das gesamte Set, in sinnvoller Reihenfolge hinzugefügt.

Praxisbeispiel (hypothetisch)

Das folgende Beispiel ist hypothetisch und enthält keine echten Daten. Halden Legal, eine erfundene Anwaltskanzlei, erhält von einem Firmenkunden einen Sicherheitsfragebogen zu den Headern ihrer Website. Der Security-Header-Checker meldet:

• HTTPS, TLS-Zertifikat: bestanden, noch 61 Tage.
• HSTS: Warnung, max-age=86400 (ein Tag).
• Mixed Content: Warnung, 2 Bilder werden über HTTP geladen (ein Partner-Badge und ein altes Teamfoto).
• Security-Header: 2 wichtige Header fehlen; nur X-Content-Type-Options ist gesetzt, und Referrer-Policy zeigt den Browser-Standard.

Die Korrekturen dauern einen Nachmittag. Die beiden Bild-URLs werden auf HTTPS geändert. Nachdem bestätigt ist, dass die Subdomain des Mandantenportals über HTTPS funktioniert, wird HSTS in zwei Schritten über eine Woche auf max-age=31536000; includeSubDomains angehoben. X-Frame-Options: SAMEORIGIN und Referrer-Policy: strict-origin-when-cross-origin werden auf dem Server ergänzt. Eine Report-Only-CSP läuft zehn Tage und deckt ein Inline-Skript des Buchungs-Widgets auf, das in eine Datei ausgelagert und über seinen Origin freigegeben wird, bevor die Richtlinie erzwungen wird. Der letzte Durchlauf besteht alle Prüfungen, und die Kanzlei beantwortet den Fragebogen mit einem Link zum geteilten Report.

Eine Checkliste für eine Stunde

1. Führen Sie den Security-Header-Checker aus und beheben Sie zuerst HTTPS- und Zertifikatsfehler.
2. Entfernen Sie den im Report aufgeführten Mixed Content.
3. Fügen Sie X-Content-Type-Options, Referrer-Policy und X-Frame-Options oder frame-ancestors hinzu.
4. Steigern Sie HSTS stufenweise auf ein Jahr, sobald jede Subdomain über HTTPS funktioniert.
5. Starten Sie eine Report-Only-CSP und planen Sie eine Auswertung ein.
6. Entfernen Sie X-Powered-By, Versionsnummern in Server und jedes X-XSS-Protection außer 0.

Wie Searvia die Sicherheit Ihrer Website im Blick behält

Der kostenlose Security-Header-Checker prüft Ihre Startseite oder jede beliebige Seite in etwa 20 Sekunden ohne Anmeldung, und derselbe Report enthält 33 weitere Prüfungen zu Suchdarstellung, Crawling, Geschwindigkeit, Mobilgeräten und E-Mail-Authentifizierung.

Ein kostenloses Searvia-Konto ergänzt einen wöchentlichen Security-Scan: passive Prüfungen von Verschlüsselung, Browser-Schutzmaßnahmen, Cookie-Flags, Softwareversionen und Schutz vor E-Mail-Spoofing, jeweils mit Anfrage und Antwort als Beleg für jeden Befund. Er bewertet Ihre CSP (zum Beispiel 'unsafe-inline' ohne Nonces oder Hashes), prüft Permissions-Policy und sucht, nachdem Sie die Inhaberschaft bestätigt haben, auch nach offen zugänglichen .env- und .git-Dateien, öffentlichen Backups, Debug-Seiten und unsicherem CORS. Write the remediation plan with AI macht aus den Befunden Konfiguration zum Einfügen (5 Credits). In bezahlten Tarifen ab Starter prüft das Uptime-Monitoring außerdem täglich Ihr TLS-Zertifikat und warnt Sie vor dem Ablauf.