HTTP-Security-Header sind Antwort-Header, die den Browser anweisen, Schutzmaßnahmen anzuwenden, die Ihre Website sonst selbst bauen müsste: bei HTTPS bleiben, nur Skripte aus vertrauenswürdigen Quellen ausführen, keine Dateitypen raten, keine Einbettung der Seite in Frames anderer Websites zulassen und weniger darüber verraten, woher ein Besucher kam. Sechs Header decken das meiste ab: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options (oder frame-ancestors in der CSP), Referrer-Policy und Permissions-Policy. Die meisten brauchen nur eine Zeile Serverkonfiguration. Die Content-Security-Policy erfordert Planung, starten Sie sie daher im Report-Only-Modus.
Die sechs Header im Überblick
HeaderSchützt vorEin StartwertStrict-Transport-SecurityVerbindungen, die auf unverschlüsseltes HTTP herabgestuft werdenmax-age=31536000Content-Security-PolicyEingeschleusten Skripten (Cross-Site-Scripting)Eine zuerst im Report-Only-Modus getestete PolicyX-Content-Type-OptionsBrowsern, die eine Datei als anderen Typ ausführennosniffX-Frame-Options oder frame-ancestorsClickjacking über FramesSAMEORIGIN und frame-ancestors ’self’Referrer-PolicyVollständigen Adressen, die an andere Websites gelangenstrict-origin-when-cross-originPermissions-PolicyAnfragen nach ungenutzten Browserfunktionencamera=(), microphone=(), geolocation=()
Strict-Transport-Security (HSTS)
Selbst mit einer Weiterleitung von HTTP auf HTTPS stellt ein Besucher, der Ihre Domain eintippt, die erste Anfrage über unverschlüsseltes HTTP, wo sie unterwegs mitgelesen oder verändert werden kann. HSTS weist den Browser an, für Ihre Domain ab sofort HTTPS zu verwenden, so lange, wie max-age in Sekunden angibt:
Strict-Transport-Security: max-age=31536000
Fangen Sie kurz an. Browser befolgen HSTS bis zum Ablauf, ein Fehler bleibt also hängen. Testen Sie ein paar Tage lang max-age=300 und erhöhen Sie dann auf ein Jahr (31536000).
includeSubDomains wendet die Regel auf jede Subdomain an. Fügen Sie es nur hinzu, wenn alle, auch alte Staging- und Mail-Hosts, über HTTPS funktionieren.
preload beantragt über hstspreload.org, die Domain fest in Browser einzubauen. Das setzt ein max-age von mindestens einem Jahr und includeSubDomains voraus. Das Entfernen dauert lange, betrachten Sie es also als dauerhaft.
Browser ignorieren HSTS in Antworten über unverschlüsseltes HTTP. Senden Sie den Header über HTTPS und behalten Sie das Zertifikat im Blick: Mit HSTS lässt sich ein abgelaufenes Zertifikat nicht wegklicken.
Content-Security-Policy
Eine Content Security Policy legt fest, woher die Seite Skripte, Styles, Bilder, Schriften und Frames laden darf und wohin Formulare senden dürfen. Bringt ein Angreifer ein Skript in die Seite, etwa über ein Kommentarfeld oder ein kompromittiertes Plugin, verweigert der Browser die Ausführung, sofern die Policy die Quelle nicht erlaubt. Von den sechs Headern ist sie der wirksamste und der, bei dem man am leichtesten etwas falsch macht, denn eine zu strenge Policy legt Ihre eigene Webanalyse, Ihr Chat-Widget oder Ihr Zahlungsformular lahm.
Mit Report-Only beginnen
Senden Sie die Policy zuerst als Content-Security-Policy-Report-Only. Der Browser setzt dann nichts durch, meldet aber jeden Verstoß an die Adresse in report-uri (oder im neueren report-to) und protokolliert ihn in der Konsole. Ein Ausgangspunkt für eine Website, die ihre eigenen Dateien ausliefert:
Content-Security-Policy-Report-Only: default-src ’self‘; script-src ’self‘; style-src ’self‘; img-src ’self‘ data:; font-src ’self‘; object-src ’none‘; base-uri ’self‘; form-action ’self‘; frame-ancestors ’self‘; report-uri /csp-report
Klicken Sie sich durch die Website, sammeln Sie ein, zwei Wochen lang die Berichte und ergänzen Sie die Quellen, die Sie wirklich nutzen, etwa Ihren Analyse- oder Zahlungsanbieter. Wenn die Berichte nur noch Dinge zeigen, die blockiert werden sollen, senden Sie dieselbe Policy als Content-Security-Policy.
Inline-Skripte: Nonces statt unsafe-inline
Eine strenge Policy blockiert Inline-<script>-Blöcke und onclick-Attribute, denn ein eingeschleustes Skript sieht genauso aus. Mit ‚unsafe-inline‘ verschwindet das Problem – und mit ihm der Großteil des Schutzes. Geben Sie stattdessen jeder Antwort eine zufällige Nonce, führen Sie sie in der Policy als ’nonce-…‘ auf und setzen Sie denselben Wert in Ihre eigenen Script-Tags; verlagern Sie Inline-Event-Handler in Skriptdateien. Tag-Manager, die eigene Skripte einfügen, brauchen besondere Sorgfalt, denn jedes Tag, das sie hinzufügen, muss ebenfalls erlaubt sein.
X-Content-Type-Options
Früher haben Browser den Typ einer Datei anhand ihres Inhalts erraten, wenn der Content-Type des Servers falsch aussah. So konnte ein hochgeladenes „Bild“ als Skript laufen. X-Content-Type-Options: nosniff schaltet dieses Raten ab. Der Header hat genau einen gültigen Wert und keinen bekannten Nachteil, solange Ihr Server korrekte Content-Types sendet. Senden Sie ihn also bei jeder Antwort.
X-Frame-Options und frame-ancestors
Bei einem Clickjacking-Angriff zeigt eine fremde Website Ihre Seite in einem unsichtbaren Frame und verleitet Besucher dazu, darauf Schaltflächen anzuklicken. X-Frame-Options: DENY verhindert jede Einbettung, SAMEORIGIN erlaubt nur Ihre eigenen Seiten. Die CSP-Direktive frame-ancestors macht dasselbe mit mehr Kontrolle, etwa mit einer Liste von Partnerseiten, und hat in Browsern, die sie unterstützen, Vorrang. Senden Sie beides: frame-ancestors für aktuelle Browser, X-Frame-Options für ältere. Der alte Wert ALLOW-FROM wird nicht mehr unterstützt; nutzen Sie also frame-ancestors für alles, was über Ihren eigenen Origin hinausgeht.
Referrer-Policy
Folgt ein Besucher einem Link, teilt der Browser der nächsten Website im Referer-Header mit, woher er kam. Ohne Einschränkung kann das die vollständige Adresse sein, samt Suchbegriff, Reset-Token oder Bestellnummer in der URL. strict-origin-when-cross-origin sendet innerhalb Ihrer eigenen Website die vollständige Adresse, an andere Websites nur die Domain und von HTTPS zu HTTP gar nichts. Das ist das Verhalten aktueller Browser, wenn der Header fehlt; ihn zu senden macht die Entscheidung aber ausdrücklich. Verwenden Sie no-referrer auf Seiten mit privaten Daten in der URL und meiden Sie unsafe-url, das alles überallhin sendet.
Permissions-Policy
Permissions-Policy, früher Feature-Policy, schaltet Browserfunktionen ab, die Ihre Website nicht nutzt – für die Seite und für jeden darin eingebetteten Frame. Eine leere Liste, (), bedeutet, dass niemand die Funktion nutzen darf:
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=()
Lassen Sie die Funktionen weg, die Sie nutzen, oder erlauben Sie sie für Ihren eigenen Origin mit (self), zum Beispiel payment=(self) in einem Shop mit Bezahl-Button.
Header, auf die Sie verzichten können
X-XSS-Protection steuerte einen Filter, den aktuelle Browser entfernt haben. Lassen Sie ihn weg oder senden Sie 0.
Expect-CT und Public-Key-Pins sind veraltet. Pinning konnte Besucher von einer Website aussperren, weshalb Browser es abgeschafft haben.
Server und X-Powered-By sind keine Security-Header, aber genaue Versionsnummern darin helfen Angreifern, einen passenden Exploit zu wählen. Kürzen Sie sie, wo Ihr Server das zulässt.
Wo Sie die Header setzen
Setzen Sie die Header an einer Stelle, so nah am Rand Ihrer Infrastruktur wie möglich: im Webserver, im CDN oder in der Middleware der Anwendung. In nginx und Apache:
# nginx (im server-Block)
add_header Strict-Transport-Security „max-age=31536000“ always;
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 Permissions-Policy „camera=(), microphone=(), geolocation=()“ always;
# Apache (.htaccess oder Virtual Host, mit mod_headers)
Header always set X-Content-Type-Options „nosniff“
Header always set Referrer-Policy „strict-origin-when-cross-origin“
Zwei nginx-Details werden oft übersehen. Ohne always werden die Header nur erfolgreichen Antworten hinzugefügt, nicht Fehlerseiten. Und ein location-Block mit einem eigenen add_header verwirft alle Header aus dem server-Block – ein einziger Cache-Header für Bilder kann dort also unbemerkt Ihre Security-Header entfernen. Achten Sie außerdem darauf, dass derselbe Header nicht doppelt gesetzt wird, vom Server und von der Anwendung oder dem CDN: Browser gehen je nach Header unterschiedlich mit Duplikaten um, legen Sie also für jeden Header eine zuständige Stelle fest.
So prüfen Sie Ihre Header
Im Terminal gibt curl -sI https://example.com die Antwort-Header aus. Prüfen Sie auch die endgültige Adresse nach Weiterleitungen, eine Fehlerseite und eine statische Datei, denn jede davon kann von einem anderen Teil Ihres Stacks ausgeliefert werden. Im Browser zeigt der Netzwerk-Tab der Entwicklertools die Header jeder Anfrage, und die Konsole zeigt CSP-Verstöße.
Oder nutzen Sie unseren kostenlosen HTTP-Header-Checker. Er listet jeden Header auf, den eine URL nach dem Folgen von Weiterleitungen sendet, markiert, welche der sechs Security-Header fehlen, weist auf einige Werte hin, die sie wirkungslos machen, etwa ein kurzes HSTS-max-age, eine CSP, die nur im Report-Only-Modus läuft, oder unsafe-url, und zeigt, wie die Seite gecacht wird und wo die Zeit verloren geht. Er prüft, ob die Header vorhanden sind; was eine Content Security Policy erlaubt, bewertet er nicht – das sollten Sie selbst prüfen.
Damit sie nicht verschwinden
Security-Header fallen selten laut aus. Sie verschwinden, wenn eine Website auf einen neuen Server umzieht, das CDN gewechselt, ein Plugin aktualisiert oder ein location-Block ergänzt wird – und die Website läuft weiter, also merkt es niemand. Ein HTTP-Monitor im Uptime-Monitoring von Uptimecheck kann bei jeder Anfrage die Antwort-Header prüfen, mit bis zu 10 Antwortprüfungen pro Monitor, zum Beispiel:
Strict-Transport-Security ist vorhanden.
X-Content-Type-Options ist gleich nosniff.
Content-Security-Policy enthält frame-ancestors.
Jede Prüfung muss bestehen, damit der Monitor als erreichbar gilt. Ein fehlender Header setzt ihn also auf down, eine zweite Prüfung bestätigt das, und Sie erhalten einen Alarm. Legen Sie die Header-Prüfungen auf einen eigenen Monitor, wenn sie nicht in die Uptime der Seite einfließen sollen. Die Prüfungen laufen bis zu jede Minute aus Stockholm, London und New York; wie Sie Antwortprüfungen einrichten, lesen Sie unter So überwachen Sie einen API-Endpunkt, den Rest der Routine in der Checkliste für die Website-Wartung.
Erfahren Sie noch am selben Tag, wenn ein Header fehlt. Testen Sie Uptimecheck 14 Tage kostenlos, ohne Kreditkarte.