Security-Header, die zählen – und welche ausgedient haben

HTTP-Antwort-Header sagen dem Browser, wie er Ihre Seiten behandeln soll: welche Skripte laufen dürfen, ob die Website in einem Frame eingebettet werden darf und ob sie immer über HTTPS geladen werden muss. Eine Handvoll davon blockiert ganze Angriffsklassen fast ohne Aufwand. Andere sind veraltet und erzeugen nur Rauschen oder sogar Risiken.

Eine Grundkonfiguration als Ausgangspunkt

Das ist ein sinnvoller Ausgangspunkt für eine HTML-Anwendung, die nur über HTTPS ausgeliefert wird. Übernehmen Sie sie nicht unverändert. Vor allem die CSP muss dazu passen, wie Ihre Seiten Skripte laden, ihre Nonce muss für jede Antwort neu sein, und HSTS-Preload lässt sich nur schwer rückgängig machen.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Content-Security-Policy: script-src 'nonce-3f9a1c7e2b' 'strict-dynamic'; object-src 'none'; base-uri 'none'; frame-ancestors 'none'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), camera=(), microphone=()
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-site

Content-Security-Policy

Die CSP beschränkt, woher Skripte und andere Ressourcen stammen dürfen. Ihre Hauptaufgabe ist es, die Ausnutzung von Cross-Site-Scripting (XSS) deutlich zu erschweren.

Das OWASP CSP Cheat Sheet bevorzugt eine strikte Richtlinie auf Basis von Nonces oder Hashes gegenüber einer langen Liste erlaubter Domains. Allowlist-Richtlinien, die zu breit oder zu kleinteilig sind, werden häufig umgangen. Eine Nonce-basierte Richtlinie sieht so aus:

Content-Security-Policy: script-src 'nonce-3f9a1c7e2b' 'strict-dynamic'; object-src 'none'; base-uri 'none'

Jedes Script-Tag trägt dann denselben Wert, etwa <script nonce="3f9a1c7e2b">. Die Nonce muss zufällig und für jede Antwort neu sein; ein fester Wert verfehlt den Zweck. Erzeugen Sie sie in Ihrer Template-Schicht. OWASP warnt vor Middleware, die jedem Script-Tag die Nonce hinzufügt, denn damit würden auch eingeschleuste Skripte legitimiert.

Sind Ihre Seiten statisch, verwenden Sie stattdessen Hashes: 'sha256-...'-Werte für jedes Inline-Skript. Jede Änderung am Skript, selbst an Leerzeichen, ändert den Hash.

Vermeiden Sie 'unsafe-inline' und 'unsafe-eval' in script-src. Sie öffnen genau das wieder, was die CSP schließen soll.

Damit bei der Einführung nichts kaputtgeht, senden Sie die Richtlinie zuerst als Content-Security-Policy-Report-Only. Browser melden dann Verstöße, ohne etwas zu blockieren. Beheben Sie, was die Berichte zeigen, und schalten Sie dann auf Durchsetzung um.

Trusted Types

Trusted Types richten sich gegen DOM-basiertes XSS, bei dem Ihr eigenes JavaScript vom Angreifer kontrollierte Zeichenketten an gefährliche APIs wie innerHTML, eval() oder das src eines Script-Elements übergibt. Sie aktivieren sie über die CSP:

Content-Security-Policy: require-trusted-types-for 'script'; trusted-types app-policy

Bei aktiver Durchsetzung löst die Übergabe einer einfachen Zeichenkette an eine dieser Senken einen Fehler aus. Der Code muss Werte übergeben, die von einer benannten Policy erzeugt wurden, meist einer, die HTML bereinigt. MDN führt die API seit Februar 2026 als Baseline, sie funktioniert also in den aktuellen Versionen der großen Browser. Beginnen Sie im Report-only-Modus, denn bestehender Code schreibt womöglich Zeichenketten direkt ins DOM.

Strict-Transport-Security und Preload

HSTS weist Browser an, sich für die in max-age angegebene Anzahl Sekunden nur über HTTPS mit Ihrer Domain zu verbinden. Mit includeSubDomains gilt die Regel auch für jede Subdomain.

Die Preload-Liste geht weiter. Browser werden mit eingebauter Liste ausgeliefert, sodass schon der erste Besuch Ihrer Domain HTTPS nutzt. Die Anforderungen auf hstspreload.org sind:

• ein gültiges Zertifikat und eine Weiterleitung von HTTP auf HTTPS auf demselben Host
• jede Subdomain wird über HTTPS ausgeliefert, auch interne
• max-age von mindestens 31536000 (ein Jahr) sowie includeSubDomains und preload
• der HSTS-Header auch bei Weiterleitungen, die von der HTTPS-Website ausgeliefert werden

Führen Sie es stufenweise ein. Die Preload-Website schlägt vor, mit max-age=300 zu beginnen, dann eine Woche (604800), dann einen Monat (2592000), und bei jedem Schritt auf Probleme zu achten. Eine Entfernung von der Preload-Liste erreicht die Nutzer erst nach Monaten; stellen Sie also sicher, dass jede Subdomain dauerhaft HTTPS unterstützen kann.

X-Content-Type-Options

X-Content-Type-Options: nosniff verhindert, dass Browser den Typ einer Datei aus ihrem Inhalt erraten. Kombinieren Sie den Header mit einem korrekten Content-Type bei jeder Antwort, einschließlich charset bei HTML, etwa text/html; charset=UTF-8.

frame-ancestors und X-Frame-Options

Clickjacking funktioniert, indem Ihre Seite unsichtbar in einem Frame auf einer anderen Website geladen wird. Die CSP-Direktive frame-ancestors legt fest, wer Sie einbetten darf, und OWASP weist darauf hin, dass sie X-Frame-Options in Browsern, die sie unterstützen, ablöst.

Zwei Details werden oft übersehen. Laut MDN greift frame-ancestors nicht auf default-src zurück; Sie müssen die Direktive also ausdrücklich setzen. Außerdem wirkt sie in einem <meta>-Tag nicht, sondern nur als Header. Für ältere Browser schadet es nicht, beides zu senden:

Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: DENY

Verwenden Sie frame-ancestors 'self', wenn Ihre eigene Website ihre Seiten einbettet. Vermeiden Sie X-Frame-Options: ALLOW-FROM, das veraltet ist. MDN weist darauf hin, dass moderne Browser dann den gesamten Header ignorieren.

Referrer-Policy

Dieser Header steuert, wie viel von der aktuellen URL im Header Referer an andere Websites gesendet wird. Wenn Sie nichts setzen, verwenden Browser standardmäßig strict-origin-when-cross-origin, das über HTTPS nur den Origin an andere Websites sendet. OWASP empfiehlt trotzdem, den Wert ausdrücklich zu setzen. Verwenden Sie no-referrer oder same-origin, wenn Ihre URLs Tokens oder personenbezogene Daten enthalten können.

Permissions-Policy

Permissions-Policy schaltet Browserfunktionen ab, die Ihre Website nicht nutzt. Eine leere Allowlist, (), deaktiviert eine Funktion für Ihre Seite und für jeden Frame darin:

Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=()

Wird eine Funktion benötigt, erlauben Sie sie möglichst eng, zum Beispiel camera=(self).

COOP und CORP

Cross-Origin-Opener-Policy: same-origin legt Ihre Seite in eine eigene Browsing-Context-Gruppe. Eine Seite, die Ihre mit window.open() öffnet, kann dann keine Referenz darauf behalten. Das schließt eine Klasse von Cross-Site-Leak-Angriffen (XS-Leaks) aus. Wenn Sie für Single Sign-on oder Zahlungen auf Pop-ups angewiesen sind, sorgt same-origin-allow-popups dafür, dass diese weiter funktionieren.

Cross-Origin-Resource-Policy: same-site verhindert, dass andere Websites Ihre Ressourcen wie Bilder oder Skripte einbetten. Cross-Origin-Embedder-Policy: require-corp wird nur für die Cross-Origin-Isolation benötigt, die Funktionen wie SharedArrayBuffer voraussetzen. Lassen Sie COEP weg, solange Sie diese Funktionen nicht brauchen, denn es blockiert Cross-Origin-Ressourcen, die nicht ausdrücklich zustimmen.

Header, die ausgedient haben

Wo Sie anfangen

1. Prüfen Sie mit unserem Security-Header-Scanner, was Ihre Website heute sendet.
2. Ergänzen Sie zuerst die risikoarmen Header: X-Content-Type-Options, Referrer-Policy, Permissions-Policy und frame-ancestors.
3. Führen Sie HSTS mit einem kurzen max-age ein und erhöhen Sie den Wert stufenweise. Ziehen Sie Preload erst in Betracht, wenn jede Subdomain bereit ist.
4. Betreiben Sie die CSP einige Wochen im Report-only-Modus, beheben Sie Verstöße und setzen Sie sie dann durch.

Wenn Sie eine neue Anwendung entwickeln und diese Header von Anfang an einplanen möchten, unterstützt Sie unser Team für sichere Softwareentwicklung.