HTTP-Sicherheits-Header: Vollständiger Leitfaden 2026

Warum Security-Header wichtig sind

HTTP-Security-Header sind Anweisungen, die von deinem Webserver gesendet werden und Browsern vorgeben, wie sie sich beim Anzeigen deiner Website verhalten sollen. Sie hinzuzufügen erfordert keine Änderungen am Code deiner Anwendung - lediglich eine Konfiguration des Webservers - und dennoch gehören sie zu den wirksamsten Schutzmaßnahmen gegen eine Vielzahl verbreiteter Webangriffe, darunter Cross-Site Scripting (XSS), Clickjacking und Content-Injection.

Viele Websites vernachlässigen Security-Header vollständig. Eine Untersuchung der eine Million meistbesuchten Websites zeigt immer wieder, dass den meisten zumindest einige kritische Header fehlen. Das ist eine vertane Chance, denn diese Header sind kostenlos und einfach hinzuzufügen.

HSTS - HTTP Strict Transport Security

HSTS ist ein Header, der Browsern mitteilt: Verbinde dich niemals über unverschlüsseltes HTTP mit dieser Website, ganz gleich, was passiert. Sobald ein Browser einmal einen HSTS-Header von deiner Website gesehen hat, stuft er alle künftigen HTTP-Anfragen automatisch auf HTTPS hoch - selbst wenn der Nutzer "http://" in die Adresszeile eingibt oder auf einen HTTP-Link klickt. Dies ist einer der wichtigsten Security-Header, die du hinzufügen kannst.

Der Header hat drei wichtige Parameter. Der Wert "max-age" teilt dem Browser mit, wie lange (in Sekunden) er sich diese Richtlinie merken soll - du solltest ihn auf mindestens ein Jahr (31536000 Sekunden) setzen. Das Flag "includeSubDomains" weitet diesen Schutz auf all deine Subdomains aus. Das Flag "preload" signalisiert Browsern, dass du in die HSTS-Preload-Liste aufgenommen werden möchtest - eine Liste, die direkt in Chrome, Firefox und andere Browser eingebaut ist, sodass selbst der allererste Besuch deiner Website geschützt ist.

Unter nginx fügst du diesen Header mit der Direktive add_header innerhalb deines server-Blocks hinzu. Unter Apache verwendest du die Header-Direktive innerhalb eines VirtualHost-Blocks. Gib stets das Schlüsselwort "always" an, um sicherzustellen, dass der Header auch bei Fehlerantworten gesendet wird.

Bevor du eine lange max-age festlegst, vergewissere dich absolut, dass deine gesamte Website - einschließlich aller Subdomains - korrekt über HTTPS funktioniert. Wenn du HSTS mit einer langen max-age setzt und dann feststellst, dass eine Subdomain kein HTTPS unterstützt, kann das Nutzer monatelang aussperren.

CSP - Content Security Policy

Die Content Security Policy ist der mächtigste verfügbare Security-Header und zugleich der komplexeste, um ihn korrekt zu konfigurieren. Sie teilt Browsern genau mit, welche Inhaltsquellen auf deiner Seite geladen werden dürfen - Skripte, Stylesheets, Bilder, Schriftarten und mehr. Dies ist deine wichtigste Verteidigung gegen Cross-Site-Scripting-Angriffe (XSS), bei denen es einem Angreifer gelingt, schädliches JavaScript in deine Seite einzuschleusen.

Eine CSP funktioniert, indem sie vertrauenswürdige Quellen auf eine Whitelist setzt. Du könntest zum Beispiel festlegen, dass Skripte nur von deiner eigenen Domain und von Google Analytics geladen werden dürfen, dass Stylesheets nur von deiner eigenen Domain stammen dürfen und dass Bilder von überall über HTTPS kommen dürfen. Jeglicher Inhalt, der diesen Regeln nicht entspricht, wird vom Browser blockiert, bevor er ausgeführt werden kann.

Am wirksamsten lässt sich eine CSP schrittweise einführen. Beginne damit, einen "Content-Security-Policy-Report-Only"-Header anstelle von "Content-Security-Policy" hinzuzufügen. Das bedeutet, dass die Richtlinie nicht erzwungen wird - Verstöße werden dir gemeldet, der Inhalt wird aber weiterhin geladen. So kannst du Verstoßmeldungen sammeln, alle legitimen Drittanbieter-Ressourcen ermitteln, die deine Website tatsächlich lädt, und deine Richtlinie aufbauen, ohne etwas zu beschädigen. Nach ein bis zwei Wochen der Datensammlung wechselst du zur erzwingenden Variante.

Eine häufige Falle ist "unsafe-inline" - eine Direktive, die Inline-Skripte und -Stile erlaubt. Zwar erleichtert sie die Einführung einer CSP, ohne deine Website zu beschädigen, doch sie verringert den gebotenen Schutz drastisch, weil die meisten XSS-Angriffe auf dem Einschleusen von Inline-Skripten beruhen. Ein besserer Ansatz ist die Verwendung von "Nonces" oder "Hashes", um bestimmte Inline-Skripte zuzulassen und eingeschleuste zu blockieren.

X-Frame-Options

Der Header X-Frame-Options steuert, ob deine Website innerhalb eines iframes auf einer anderen Domain eingebettet werden darf. Dies schützt vor Clickjacking-Angriffen, bei denen ein Angreifer deine Website in ein unsichtbares iframe legt, das über seiner eigenen Seite liegt. Der Besucher glaubt, auf etwas auf der Seite des Angreifers zu klicken, klickt in Wahrheit aber auf deine Website - und autorisiert dabei womöglich eine Transaktion, klickt auf einen "Akzeptieren"-Button oder führt eine andere Aktion aus, ohne es zu merken.

Der empfohlene Wert ist "SAMEORIGIN", der das Einbetten deiner Website in iframes nur von Seiten deiner eigenen Domain aus erlaubt. "DENY" verhindert das Einbetten vollständig. Die ältere Option "ALLOW-FROM" ist veraltet und wird von modernen Browsern nicht mehr unterstützt.

Beachte: Wenn du eine moderne CSP konfiguriert hast, kannst du anstelle von X-Frame-Options die CSP-Direktive "frame-ancestors" verwenden - sie bietet eine feinkörnigere Kontrolle. Für maximale Kompatibilität über alle Browser hinweg ist es jedoch empfehlenswert, beide einzubinden.

X-Content-Type-Options

Dieser einfache, aber wichtige Header hat einen einzigen Wert: "nosniff". Er verhindert, dass Browser "MIME-Sniffing" betreiben - also raten, welche Art von Inhalt eine Datei enthält, anhand ihres tatsächlichen Inhalts statt anhand des deklarierten Content-Type-Headers.

MIME-Sniffing klingt harmlos, lässt sich aber ausnutzen. Wenn ein Angreifer dich dazu bringen kann, eine Datei zu hosten, die dem Content-Sniffer eines Browsers wie HTML oder JavaScript erscheint - selbst wenn du sie für eine Bild- oder Textdatei hältst, könnte der Browser sie als Skript ausführen. Das Hinzufügen von "nosniff" weist Browser an, stets den deklarierten Inhaltstyp zu respektieren und niemals zu raten.

Referrer-Policy

Wenn ein Nutzer von deiner Website aus auf einen Link zu einer anderen Seite klickt, fügen Browser automatisch einen "Referer"-Header hinzu (beachte die Falschschreibung - sie ist historisch bedingt), der der Zielseite mitteilt, woher der Nutzer kam. Dadurch können unbeabsichtigt sensible Informationen nach außen gelangen, wenn deine URLs Sitzungstokens, Suchanfragen oder andere private Daten im Query-String enthalten.

Der Header Referrer-Policy steuert, welche Informationen gesendet werden. Der empfohlene Wert "strict-origin-when-cross-origin" sendet die vollständige URL bei Anfragen desselben Origins (nützlich für deine eigene Analyse), sendet bei Cross-Origin-Anfragen jedoch nur die Domain (nicht die vollständige URL). Das schützt sensible URL-Parameter und bewahrt zugleich nützliche Referrer-Informationen für deine eigene Website.

Permissions-Policy

Die Permissions-Policy (früher Feature-Policy genannt) steuert, welche Browserfunktionen und APIs deine Seite nutzen darf. Dazu zählen potenziell sensible Funktionen wie Kamera, Mikrofon, Geolokalisierung, die Payment-Request-API und mehr. Indem du Funktionen, die du nicht nutzt, ausdrücklich deaktivierst, verhinderst du, dass Drittanbieter-Skripte (Werbenetzwerke, Analysetools, eingebettete Inhalte) auf diese Funktionen zugreifen, selbst wenn sie es versuchen.

Häufig gestellte Fragen

Wird eine CSP meine Website beschädigen? Anfangs möglicherweise. Eine CSP blockiert alles, was nicht ausdrücklich erlaubt ist. Wenn du Inline-Skripte, Inline-Stile oder Drittanbieter-Ressourcen hast, die du nicht auf die Whitelist gesetzt hast, werden sie blockiert. Die Lösung besteht darin, zunächst den Report-Only-Modus zu verwenden und Zeit in das Sammeln von Verstoßmeldungen zu investieren, bevor du zur Erzwingung übergehst.

Was ist der Server-Header und sollte ich ihn verbergen? Der Server-Header verrät die Software und Version deines Webservers - zum Beispiel "nginx/1.24.0". Diese Information ist nützlich für Angreifer, die bekannte Schwachstellen bestimmter Softwareversionen ausnutzen wollen. Du solltest diesen Header unterdrücken oder vereinheitlichen. Setze in nginx "server_tokens off". Verwende in Apache "ServerTokens Prod".

Wirken sich diese Header auf die Performance der Website aus? Vernachlässigbar. Die Header fügen jeder HTTP-Antwort einige Bytes hinzu, haben aber keinen nennenswerten Einfluss auf die Ladezeit. Die Sicherheitsvorteile überwiegen jeden geringfügigen Mehraufwand bei Weitem.

Sollte ich Security-Header sowohl zu HTTP- als auch zu HTTPS-Antworten hinzufügen? Ja - konfiguriere sie für beide, aber denke daran, dass HSTS nur über HTTPS gesendet werden sollte. Über HTTP gesendetes HSTS wird ignoriert und könnte für Verwirrung sorgen.