HTTP-Sicherheitsheader, die wichtig sind: CSP, HSTS, X-Content-Type-Options, X-Frame-Options und Referrer-Policy erklaert
Warum HTTP-Antwortheader fuer die Sicherheit wichtig sind
Jede HTTP-Antwort enthaelt Header -- Metadatenzeilen, die vor dem Body gesendet werden und steuern, wie der Browser den Inhalt behandelt. Die meisten Header sind prosaisch (Content-Type, Cache-Control), aber eine bestimmte Gruppe von Sicherheitsheadern weist den Browser an, Einschraenkungen durchzusetzen, die ganze Angriffskategorien blockieren. Es handelt sich nicht um theoretische Haertungsmassnahmen; es sind praktische Verteidigungen gegen Angriffsklassen, die regelmaessig in OWASP's Top 10 und CVE-Datenbanken auftauchen. Ihre Einrichtung kostet leistungsmaessig kaum etwas -- sie fuegen jeder Antwort etwa 200-400 Bytes hinzu -- und Tools wie securityheaders.com vergeben Noten fuer jede oeffentliche URL, sodass Sie sofort sehen koennen, welche Header fehlen.
Der zentrale Punkt ist, dass Sicherheitsheader vom Browser und nicht vom Server durchgesetzt werden. Der Server kuendigt eine Richtlinie an; der Browser setzt sie durch. Das bedeutet, dass eine falsch konfigurierte Headereinstellung auf einer hochfrequentierten Website gleichzeitig den Browser jedes Besuchers beeinflusst. Umgekehrt korrigiert das Hinzufuegen der richtigen Header in einer einzigen Bereitstellung jahrelang angesammeltes Risiko. Die fuenf hier behandelten Header -- CSP, HSTS, X-Content-Type-Options, X-Frame-Options und Referrer-Policy -- zielen jeweils auf ein anderes Browserverhalten ab, das Angreifer ausnutzen koennen.
Content-Security-Policy: die XSS-Firewall
Cross-Site Scripting (XSS) ist die haeufigste Web-Schwachstelle in OWASP's Top 10. Ein Angreifer, der ein <script>-Tag in Ihr HTML einfuegen kann, kann Sitzungs-Cookies stehlen, Benutzer umleiten oder Formulardaten exfiltrieren. Content-Security-Policy (CSP) ist ein auf einer Whitelist basierender Header, der dem Browser mitteilt, welchen Quellen fuer Skripte, Stile, Bilder, Schriftarten und andere Ressourcentypen vertraut wird. Die Direktive Content-Security-Policy: default-src 'self' erlaubt nur Ressourcen vom gleichen Ursprung und blockiert alle externen Skripte sowie Inline-<script>-Bloecke. Eine script-src-Direktive ueberschreibt den Standard speziell fuer JavaScript.
Die groesste CSP-Falle ist das Schluessewort unsafe-inline. Das Hinzufuegen von script-src 'unsafe-inline' aktiviert Inline-Skripte wieder und macht den XSS-Schutz von CSP vollstaendig zunichte, ist aber die meistgesuchte Umgehungsloesung, wenn eine Website nach der Aktivierung von CSP nicht mehr funktioniert. Die richtige Alternative sind Nonces: Jeder Seitenaufruf generiert einen kryptografisch zufaelligen Wert, der als script-src 'nonce-r4nd0m' im Header und als nonce="r4nd0m" in jedem legitimen <script>-Tag enthalten ist. Ein eingeschleustes Skript ohne den passenden Nonce wird selbst dann blockiert, wenn es inline erscheint. Fuer Teams, die noch nicht bereit fuer eine strikte Richtlinie sind, liefert Content-Security-Policy-Report-Only Verstoessmeldungen an einen Collector-Endpunkt, ohne etwas zu blockieren -- eine sichere Moeglichkeit, die Auswirkungen einer Richtlinie zu messen, bevor sie durchgesetzt wird.
HTTP Strict Transport Security: HTTPS-Downgrade-Angriffe verhindern
SSL-Stripping ist ein Downgrade-Angriff, der 2009 oeffentlich auf der Black Hat demonstriert wurde. Ein aktiver Angreifer auf dem Pfad fangen die urspruengliche HTTP-Anfrage des Benutzers (vor jeder Weiterleitung zu HTTPS) ab und leitet sie als reines HTTP an den Ursprungsserver weiter, waehrend er die verschluesselte Verbindung an den Benutzer zuruecksendet. Der Benutzer sieht in einigen Browsern ein Schloss, aber die Verbindung zwischen dem Angreifer und dem Server ist die unverschluesselte -- Zugangsdaten und Sitzungs-Cookies sind im Klartext sichtbar. HTTP Strict Transport Security (HSTS) schliesst dieses Fenster, indem es Browser anweist, HTTP-Verbindungen fuer eine Domain vollstaendig abzulehnen, fuer einen durch die max-age-Direktive in Sekunden definierten Zeitraum.
Ein typischer starker HSTS-Header lautet Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. Das max-age von 31536000 Sekunden entspricht einem Jahr -- das Minimum fuer die Aufnahme in die HSTS-Vorladelist. includeSubDomains erweitert die Richtlinie auf jede Subdomain. preload signalisiert die Absicht, in die mit dem Browser gelieferte Vorladeliste auf hstspreload.org aufgenommen zu werden; einmal auf dieser Liste werden Browser HTTP-Verbindungen auch dann ablehnen, wenn sie die Website noch nie besucht und den Header erhalten haben. Die entscheidende Einschraenkung: HSTS muss ueber eine gueltige HTTPS-Antwort geliefert werden. Ein ueber HTTP gesendeter Header wird ignoriert. Testen Sie, bevor Sie includeSubDomains bereitstellen -- wenn eine Subdomain kein gueltiges TLS-Zertifikat hat, werden Benutzer fuer den gesamten max-age-Zeitraum gesperrt.
X-Content-Type-Options und X-Frame-Options: zwei Sicherheitsverbesserungen mit Einzelwert
MIME-Sniffing ist ein Legacy-Verhalten, bei dem einige Browser die ersten Bytes einer Antwort untersuchen, um den Inhaltstyp zu erraten und den Content-Type-Header zu ueberschreiben. Internet Explorer war der aggressivste MIME-Sniffer; er wuerde eine .jpg-Datei als HTML ausfuehren, wenn die ersten Bytes wie Markup aussahen. Ein Angreifer, der Inhalte auf Ihre Website hochladen kann (ein Bild, eine Protokolldatei), kann eine Payload erstellen, die als Skript ausgefuehrt wird, wenn der Browser sie erschnueffelt. X-Content-Type-Options: nosniff weist alle modernen Browser an, dem deklarierten Content-Type zu vertrauen und das Sniffing vollstaendig zu ueberspringen. Es hat genau einen gueltigen Wert -- nosniff -- und es gibt keinen Grund, ihn nicht bei jeder Antwort zu setzen.
Clickjacking bettet Ihre Website in einen <iframe> auf einer vom Angreifer kontrollierten Seite ein und legt dann transparente Schaltflaechen ueber, damit Benutzer unwissentlich auf UI-Elemente auf Ihrer Website klicken. X-Frame-Options: DENY verhindert, dass Ihre Seite von jemandem eingebettet wird; X-Frame-Options: SAMEORIGIN erlaubt das Einbetten nur durch Seiten desselben Ursprungs. Die ALLOW-FROM uri-Variante ist veraltet und wird von aktuellen Browsern nicht unterstuetzt. Das moderne Aequivalent ist die CSP frame-ancestors-Direktive (frame-ancestors 'none' entspricht DENY, frame-ancestors 'self' entspricht SAMEORIGIN), die zusaetzlich mehrere erlaubte Urspruenge unterstuetzt. Da nicht alle Browser in allen Kontexten frame-ancestors pruefen, bietet das gleichzeitige Setzen von X-Frame-Options und einer CSP frame-ancestors-Direktive eine tiefengestaffelte Verteidigung.
Referrer-Policy: Informationslecks durch den Referer-Header kontrollieren
Der HTTP-Referer-Header (aufgrund eines historischen Tippfehlers im RFC mit nur einem 'r' geschrieben) sendet die vollstaendige URL der Seite, von der der Benutzer navigiert ist, an jede externe Ressource, die diese Seite laedt -- Bilder, Skripte, Stylesheets und die Ziele von Link-Klicks. Wenn ein angemeldeter Benutzer /account/reset?token=eyJ... besucht und diese Seite ein Drittanbieter-Analyseskript laedt, traegt die Anfrage des Skripts die vollstaendige URL einschliesslich des Reset-Tokens im Referer-Header. Token-Lecks ueber den Referrer sind eine gut dokumentierte Schwachstellenklasse; GitHub hat 2020 eine auf dem Referrer basierende Token-Exposition behoben.
Der Referrer-Policy-Header ersetzt den aelteren Meta-Referrer-Mechanismus und Umgehungsloesungen zur Unterdrueckung des Referer-Headers. Die Richtlinie strict-origin-when-cross-origin ist der empfohlene Standard: Sie sendet die vollstaendige URL fuer Same-Origin-Anfragen (nuetzlich fuer interne Analysen), aber nur den nackten Ursprung (https://example.com) fuer Cross-Origin-Anfragen und nichts bei der Navigation von HTTPS zu HTTP. no-referrer sendet ueberhaupt nichts und maximiert den Datenschutz, bricht aber jede Analytik, die auf dem Referrer basiert. unsafe-url sendet immer die vollstaendige URL einschliesslich Pfad und Abfragestring -- der Browser-Standard vor 2020 und die Quelle der meisten historischen Referrer-Lecks. Chrome, Firefox und Safari haben strict-origin-when-cross-origin alle in 2020-2021 als Standard uebernommen, wenn kein Richtlinien-Header vorhanden ist, aber das explizite Setzen stellt ein konsistentes Verhalten in allen Browserversionen sicher.
Eine praktische Sicherheits-Header-Baseline fuer jede Website
Fuer eine statische Website oder eine einfache Webanwendung decken vier Header die haeufigsten Angriffsvektoren mit minimaler Konfigurationskomplexitaet ab: X-Content-Type-Options: nosniff (immer, eine Zeile); X-Frame-Options: SAMEORIGIN (es sei denn, Ihre Website muss legitim eingebettet werden); Referrer-Policy: strict-origin-when-cross-origin; und Strict-Transport-Security: max-age=31536000; includeSubDomains (sobald Sie bestaetigt haben, dass jede Subdomain HTTPS verwendet). CSP erfordert mehr Planung -- beginnen Sie mit Content-Security-Policy-Report-Only und einem Reporting-Endpunkt, sammeln Sie einige Tage lang Verstoesse, und schreiben Sie dann eine Richtlinie, die nur das erlaubt, was Sie tatsaechlich verwenden.
Der Speicherort der Header-Konfiguration haengt von Ihrem Stack ab: Nginx verwendet add_header-Direktiven im Server-Block; Apache verwendet Header always set in httpd.conf oder .htaccess; Vercel, Netlify und Cloudflare Pages haben jeweils eine Header-Konfigurationsdatei oder eine Dashboard-Einstellung. Die meisten CDNs erlauben die Header-Injektion am Edge, was gegenueber Headern auf Anwendungsebene vorzuziehen ist, da das CDN sie auch fuer gecachte Antworten liefert. Das TeaFun HTTP-Headers-Checker-Tool ruft jede oeffentliche URL ab und zeigt an, welche Sicherheitsheader vorhanden sind, ihre Werte und eine Kurzreferenzerklaerung, was jeder einzelne tut -- verwenden Sie es, um eine Website vor und nach der Bereitstellung von Header-Aenderungen zu pruefen.