Security Headers: Funktion und sicherer Einsatz
Autor: Redaktion Domeny.ForSale Veröffentlicht
Kurz erklärt: Security Headers sind Antwortheader von HTTP, die dem Browser Regeln für den sicheren Umgang mit einer Website vorgeben. Sie helfen unter anderem, die Ausführung unerwünschter Skripte, die Einbettung der Seite in fremde Frames und die Offenlegung von Informationen beim Wechsel zwischen Websites einzuschränken. Sie ersetzen weder sicheren Code noch Updates, bilden aber eine zusätzliche Schutzschicht.
So funktionieren Sicherheitsheader
Wenn der Browser eine Seite abruft, sendet der Server ihren Inhalt sowie Metadaten, also Informationen zur Antwort. Die Header von HTTP sind Teil dieser Metadaten. Sie erscheinen nicht im Seitentext, ermöglichen es dem Browser aber, die Nutzung der empfangenen Ressourcen einzuschränken.
Sicherheitsheader können eine verschlüsselte Verbindung vorschreiben, erlaubte Quellen für Skripte festlegen oder die Einbettung der Seite in einen Frame auf einer anderen Website verbieten. Üblicherweise werden sie in der Konfiguration des Servers, der Anwendung, eines Reverse-Proxys oder eines CDN eingerichtet. Die beiden Letzteren sind der eigentlichen Anwendung bei der Auslieferung von Inhalten vorgeschaltet.
Diese Schutzmaßnahmen werden vor allem vom Browser durchgesetzt. Sie verhindern nicht, dass andere Werkzeuge Anfragen direkt an die Anwendung senden. Deshalb ersetzen sie keine serverseitige Prüfung der Zugriffsrechte.
Die wichtigsten Security Headers und ihre Einsatzbereiche
Es gibt keine einheitliche Konfiguration, die für jede Website geeignet ist. Die folgenden Header schützen vor unterschiedlichen Bedrohungen und müssen an die Funktionsweise der Website angepasst werden.
| Header | Zweck | Worauf zu achten ist |
|---|---|---|
Content-Security-Policy | Legt unter anderem erlaubte Quellen für Skripte, Styles und andere Ressourcen fest. | Eine zu restriktive Richtlinie kann Formulare, Zahlungen oder Analysefunktionen blockieren. |
Strict-Transport-Security | Schreibt dem Browser vor, für einen festgelegten Zeitraum HTTPS zu verwenden. | Eine lange Gültigkeitsdauer und die Einbeziehung von Subdomains erfordern eine entsprechend vorbereitete Infrastruktur. |
X-Content-Type-Options | Schränkt mit dem Wert nosniff die Erkennung eines Ressourcentyps ein, der von der Serverangabe abweicht. | Der Server muss den korrekten Content-Type senden, etwa für Skripte und Stylesheets. |
Referrer-Policy | Steuert, welche Informationen zur Seitenadresse im Header Referer übermittelt werden. | Die Einstellung sollte sowohl den Datenschutz als auch die Anforderungen eingebundener Dienste berücksichtigen. |
Permissions-Policy | Beschränkt den Zugriff auf ausgewählte Browserfunktionen, etwa Kamera oder Standortbestimmung. | Die Unterstützung einzelner Direktiven hängt vom Browser ab. |
X-Frame-Options | Schränkt die Einbettung der Seite in Frames ein. | Bietet weniger flexible Möglichkeiten als die Direktive frame-ancestors in CSP. |
CSP, ausgeschrieben Content Security Policy, hilft, die Folgen von XSS zu begrenzen. Bei solchen Angriffen wird unerwünschter Code im Kontext der Seite ausgeführt. Eine Liste vertrauenswürdiger Domains allein bietet keinen vollständigen Schutz: Entscheidend sind die konkreten Direktiven, die Art des Ladens von Skripten und der Verzicht auf zu weit gefasste Ausnahmen.
Vor Clickjacking schützt unter anderem die Direktive frame-ancestors in CSP. Bei diesem Angriff werden Nutzer dazu verleitet, ein Element einer Seite anzuklicken, die in einer fremden Website versteckt eingebettet ist. Die Direktive kann das Einbetten vollständig verbieten oder nur bestimmten Websites erlauben.
Beispiel: Website mit Formular und externen Diensten
Angenommen, eine Unternehmenswebsite nutzt ein Kontaktformular, eine Karte und ein externes Analysewerkzeug. Eine CSP, die ausschließlich Ressourcen der eigenen Domain erlaubt, kann die Karte und die Analysefunktionen außer Betrieb setzen. Deshalb muss vor der Einführung geklärt werden, von wo die Seite Skripte, Styles, Bilder und Frames lädt und wohin sie Anfragen sendet.
Soll die Website in keinem Frame eingebettet werden dürfen, kann ein entsprechender Ausschnitt der Richtlinie so aussehen:
Content-Security-Policy: frame-ancestors 'none'
Dies ist ausschließlich eine Regel für die Einbettung, keine vollständige CSP. Sie beschränkt weder Skriptquellen noch Netzwerkverbindungen. Verwendet die Website bereits eine CSP, sollte die Regel gezielt in die bestehende Konfiguration integriert werden, statt ungeprüft eine weitere Richtlinie hinzuzufügen.
Für eine Website, die weder Kamera noch Mikrofon benötigt, kommt folgende Einstellung infrage:
Permissions-Policy: camera=(), microphone=()
Diese Einstellung sollte nicht in eine Anwendung für Videogespräche übernommen werden. Ein sinnvoller Header schränkt unnötige Möglichkeiten ein, nicht die Funktionen, die Nutzer benötigen.
Header prüfen und sicher einführen
Am einfachsten öffnest du die Entwicklertools des Browsers, wechselst zum Netzwerk-Tab, lädst die Seite neu und wählst die Anfrage für das Hauptdokument aus. Im Bereich der Antwortheader kannst du prüfen, was der Browser tatsächlich erhalten hat. Ein Eintrag in der Serverkonfiguration allein bedeutet noch nicht, dass er auch beim Nutzer ankommt.
Eine sinnvolle Reihenfolge für die Einführung:
- Prüfe repräsentative Adressen: Startseite, Anmeldung, Formulare und Fehlerseiten. Die Antworten können unterschiedliche Schichten der Infrastruktur durchlaufen.
- Kläre, an welcher Stelle du die Header verwaltest. Anwendung, Server und CDN sollten Einstellungen nicht versehentlich überschreiben oder widersprüchliche Regeln hinzufügen.
- Bereite die CSP im Modus
Content-Security-Policy-Report-Onlyvor. Damit lassen sich Verstöße beobachten, ohne Ressourcen zu blockieren. Das Sammeln von Berichten erfordert eine zusätzliche Konfiguration. - Teste wichtige Nutzeraktionen, darunter die Anmeldung, das Absenden eines Formulars und gegebenenfalls die Zahlung.
- Aktiviere die Durchsetzung der Richtlinie und beobachte nach der Einführung auftretende Fehler.
Führe HSTS, den über Strict-Transport-Security aktivierten Mechanismus, erst ein, wenn HTTPS zuverlässig funktioniert. Der Parameter includeSubDomains bezieht auch Subdomains ein. Prüfe deshalb vor seiner Verwendung auch weniger offensichtliche Dienste. Überprüfe die aktuelle Syntax und die Unterstützung der Direktiven anhand der offiziellen Dokumentation der verwendeten Plattform und der Browser.
Was das Ergebnis eines Sicherheitsscanners nicht aussagt
Ein Scanner kann fehlende Header oder riskante Werte erkennen. Seine Bewertung ist jedoch kein Beleg für die Sicherheit der Anwendung. Manche Richtlinien sind nur für bestimmte Einsatzbereiche nötig. Sie allein für eine bessere Bewertung hinzuzufügen, kann eingebundene Dienste beeinträchtigen.
Header beheben weder fehlerhafte Zugriffsrechte noch Schwachstellen in der Datenbank oder die Offenlegung geheimer Zugangsdaten im Code. Prüfe zunächst die tatsächlichen Antworten deiner Website und wähle eine Änderung aus, deren Wirkung du vor der Veröffentlichung überprüfen kannst.
Siehe auch: Was ist CSP?
Lesen Sie auch
