PlattformWissen & MethodikWas Sicherheitsheader leisten
Lokal & kontrolliert
WISSEN · FÜR ALLE, DIE EINE WEBSITE BETREIBEN

Was Sicherheitsheader leisten

Welche Antwort-Header eine Website schützen, was sie bewirken und was sie nicht leisten

Geprüft am 21. September 2026 · etwa 5 Minuten Lesezeit

Kurz gesagt

Sicherheitsheader sind Anweisungen, die ein Server mit jeder Antwort an den Browser schickt: nur verschlüsselt verbinden, keine eingeschleusten Skripte ausführen, sich nicht in fremde Seiten einbetten lassen, Dateitypen nicht erraten. Die wichtigsten sind Strict-Transport-Security, Content-Security-Policy, der Schutz vor Einbettung und X-Content-Type-Options. Sie wehren ganze Klassen von Angriffen ab oder erschweren sie, sofern der Browser sie kennt — aber sie ersetzen keine sichere Anwendung, und ein fehlender Header ist noch kein Angriff.

Was ein Antwort-Header ist

Wenn dein Browser eine Seite abruft, schickt der Server vor dem eigentlichen Inhalt ein paar Zeilen mit: welcher Dateityp folgt, wie lange der Browser ihn zwischenspeichern darf, ob ein Cookie gesetzt wird. Diese Zeilen heißen Header. Einige davon sind Sicherheitsanweisungen — sie sagen dem Browser, was er mit dieser Antwort nicht tun soll.

Das Besondere daran: Der Schutz läuft im Browser jedes Besuchers, nicht auf dem Server. Eine Zeile in der Serverkonfiguration schützt damit alle, die die Seite aufrufen, ohne dass sie etwas tun müssen.

Die wichtigen Header und was sie tun

Sicherheitsheader im Überblick
HeaderWogegenGuter AusgangswertWorauf achten
Strict-Transport-Securitydas Herabstufen auf unverschlüsseltes HTTPals Ziel max-age=31536000; includeSubDomainsstufenweise einführen, etwa 5 Minuten, 1 Woche, 1 Monat; includeSubDomains erst, wenn alle Subdomains — auch interne — HTTPS beherrschen; wirkt erst nach dem ersten verschlüsselten Besuch; siehe HSTS (Strict-Transport-Security)
Content-Security-Policyeingeschleuste Skripte (Cross-Site-Scripting (XSS))eine strikte Richtlinie mit Nonce oder HashListen erlaubter Adressen schützen meist wenig; siehe Content Security Policy verstehen
frame-ancestors in der CSP oder X-Frame-Optionsunsichtbares Einbetten (Clickjacking)frame-ancestors 'none' beziehungsweise DENYeine durchgesetzte frame-ancestors-Angabe hat Vorrang
X-Content-Type-Optionsdass der Browser einen Dateityp errät und etwas als Skript ausführtnosniffnur dieser eine Wert ist vorgesehen
Referrer-Policydie Weitergabe vollständiger Adressen an fremde Seitenstrict-origin-when-cross-origin oder no-referrerunsafe-url gibt in Chrome und Edge die volle Adresse weiter, auch an unverschlüsselte Seiten; Firefox und Safari übergehen den Wert bei fremden Seiten
Permissions-Policydass Seite oder eingebettete Inhalte Kamera, Standort und Ähnliches nutzenetwa camera=(), geolocation=(), microphone=()wirkt nur in Chrome, Edge und anderen Chromium-Browsern; ein einziger Syntaxfehler verwirft den ganzen Header
Cross-Origin-Opener-Policydass fremde Fenster auf deines zugreifensame-originkann Anmeldungen über Popup-Fenster anderer Anbieter stören
Set-Cookie mit Attributenden Diebstahl und Missbrauch von Sitzungs-CookiesSecure; HttpOnly; SameSite=Laxsiehe Cookie-Attribute (Secure, HttpOnly, SameSite)

Dazu kommt für Seiten mit persönlichen Inhalten Cache-Control: no-store, damit weder ein gemeinsam genutzter Zwischenspeicher noch der Browser eine Seite mit Kontodaten aufbewahrt. Und für Schnittstellen, die fremde Websites lesen dürfen, die Regeln von CORS (Cross-Origin Resource Sharing) — eng gefasst, nie mit einem Stern zusammen mit Anmeldedaten.

Was du weglassen oder entfernen kannst

  • X-XSS-Protection: veraltet. Der Filter, den er steuerte, konnte laut MDN in sonst sicheren Seiten selbst Lücken schaffen; OWASP rät, den Header wegzulassen oder auf 0 zu setzen.
  • Expect-CT und Public-Key-Pins: von den Browsern entfernt. Sie bewirken nichts mehr.
  • Feature-Policy: abgelöst durch Permissions-Policy.
  • Server mit Versionsnummer, X-Powered-By und ähnliche Zeilen: Sie verraten, welche Software in welcher Fassung läuft. OWASP rät, sie zu entfernen — mit dem ehrlichen Zusatz, dass Angreifer die Software auch auf anderen Wegen erkennen können.
Zum Preloading von HSTS

Manche Anleitungen empfehlen, die eigene Adresse in die fest eingebaute HSTS-Liste der Browser eintragen zu lassen. Die Betreiber dieser Liste raten inzwischen selbst davon ab, weil viele Browser Aufrufe ohnehin auf HTTPS heben — und ein Eintrag lässt sich nur mühsam und über Monate wieder entfernen.

Ein Beispiel: vorher, und so hält es HexWarte

So sehen die Header vieler kleiner Websites aus — die Seite funktioniert, geschützt ist sie kaum:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Server: Apache/2.4.41 (Ubuntu)
X-Powered-By: PHP/7.4.3
Set-Cookie: PHPSESSID=…; path=/
  • Es fehlen HSTS, eine Content Security Policy, der Schutz vor Einbettung und nosniff.
  • Server und X-Powered-By nennen Software und Fassung.
  • Das Sitzungs-Cookie trägt weder Secure noch HttpOnly noch SameSite.

Und das sind die Sicherheitsheader, mit denen hexwarte.de am 21. September 2026 antwortete (ein Auszug) — die Zeilen kannst du mit der Anleitung zum Kopieren selbst nachprüfen:

Strict-Transport-Security: max-age=31536000
Content-Security-Policy: default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self'; font-src 'self'; connect-src 'none'; media-src 'none'; object-src 'none'; frame-src 'none'; frame-ancestors 'none'; base-uri 'none'; form-action 'none'; worker-src 'none'; manifest-src 'none'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: no-referrer
Permissions-Policy: accelerometer=(), autoplay=(), camera=(), display-capture=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=()
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin

Die Richtlinie verbietet zuerst alles und erlaubt dann nur, was die Seite braucht: Skripte, Stile, Bilder und Schriften von der eigenen Adresse. Das geht, weil HexWarte kein einziges Skript im HTML selbst stehen hat und keine fremden Inhalte lädt. Für eine Seite mit Analysewerkzeug, Kartendienst oder eingebetteten Videos sähe eine gute Richtlinie anders aus. Cross-Origin-Resource-Policy verbietet fremden Seiten, Dateien von hexwarte.de einzubinden. HSTS gilt hier ohne includeSubDomains, also für hexwarte.de mit allen Unterseiten, nicht aber für Subdomains wie tls.hexwarte.de.

Was du brauchst, um Header zu setzen

  • Zugriff auf die Stelle, an der die Antworten entstehen: die Konfiguration des Webservers (etwa add_header bei nginx, Header set bei Apache), ein Menü im Hosting-Paket, die Einstellungen eines vorgeschalteten Dienstes oder den Code der Anwendung.
  • Bevor du HSTS setzt: eine vollständig und dauerhaft funktionierende Verschlüsselung, mit includeSubDomains auch für alle Subdomains. Fällt sie später aus, kommen Besucher bis zum Ablauf von max-age nicht mehr auf die Seite.
  • Für eine Content Security Policy einen Überblick über alle Skripte und fremden Dienste der Seite; siehe Content Security Policy schrittweise einführen.
  • Eine Möglichkeit, das Ergebnis zu prüfen: die Entwicklerwerkzeuge des Browsers oder die Header-Werkstatt von HexWarte.

Was dieser Artikel nicht sagt

  • Header ersetzen keine sichere Anwendung. Eine Lücke im Code bleibt eine Lücke; die Header begrenzen, was ein Angreifer damit anfangen kann.
  • Ein fehlender Header ist kein Beweis für einen Angriff und auch keine Lücke im engeren Sinn. Es fehlt eine Schutzschicht, und wie schwer das wiegt, hängt von der Seite ab.
  • Die Werte in der Tabelle sind Ausgangspunkte, keine Vorlage zum Kopieren. Welche Richtlinie passt, hängt davon ab, was die Seite lädt.
  • Wo sich die Fachquellen widersprechen, etwa beim Preloading von HSTS, sagt der Artikel das und folgt der Stelle, die die Sache verantwortet.