HTTP-Security-Header einfach erklärt: Welche schützen und welche nur vorhanden sind

HTTP-Sicherheitsheader geben dem Browser Regeln für eine Antwort vor. Für die Schutzwirkung zählen die Werte, das Zusammenspiel der Regeln und die Unterstützung im Browser. Eine Liste vorhandener Header allein genügt nicht.

CSP begrenzt unter anderem Skripte und Ressourcen. HSTS verlangt HTTPS für bekannte Hosts. X-Frame-Options beziehungsweise CSP frame-ancestors begrenzen das Einbetten in Frames. Referrer-Policy steuert Angaben zur Herkunft einer Anfrage. Permissions-Policy beschränkt unterstützte Browserfunktionen; eine Sperre von Kamera oder Standort kann benötigte Funktionen durchaus unterbrechen.

CSP: Eine erlaubte Ausnahme hebt nicht alles auf

Eine Content-Security-Policy ergänzt sichere Ausgabe und Eingabeverarbeitung als zusätzliche Schutzschicht gegen Cross-Site-Scripting (XSS). Bei einem XSS-Angriff läuft eingeschleuster Code im Browser als Teil der betroffenen Seite. CSP ersetzt keine Fehlerbehebung in der Anwendung. Die konkrete Direktive entscheidet: script-src betrifft Skripte, img-src Bilder; default-src dient vielen Ressourcendirektiven als Rückfall.

Bei default-src 'self' 'unsafe-inline' sind eingebettete Skripte erlaubt, sofern keine speziellere Skriptregel greift. Externe Ressourcen bleiben grundsätzlich auf die eigene Origin begrenzt. Die Policy ist damit geschwächt, aber nicht vollständig wirkungslos. Ein 'unsafe-inline' ausschließlich in style-src erlaubt nicht automatisch eingebettete Skripte.

'unsafe-eval' erlaubt bestimmte Auswertungen von Zeichenfolgen als Code und ist von eingebetteten Skripten zu unterscheiden. Auch default-src * erlaubt nicht automatisch Inline-Skripte oder eval. Eine speziellere Direktive wie script-src-elem kann die Bewertung erneut verändern.

Nonces und Hashes gezielt verwenden

Eine kryptografisch zufällige, pro Antwort neue Nonce kann erlaubte Skripte kennzeichnen. Der Wert muss sowohl im passenden CSP-Quelleneintrag als auch am Skriptelement stehen. Ein Hash ist ein aus dem Skriptinhalt berechneter Prüfwert. Die Regel erlaubt den exakt passenden Skriptinhalt. Änderungen an Leerzeichen können deshalb einen neuen Hash erfordern.

In der für das Skript maßgeblichen Quellenliste verdrängt eine Nonce oder ein Hash in unterstützenden Browsern die pauschale Inline-Erlaubnis. Eine Nonce in einer anderen Direktive genügt nicht. Statisch wiederverwendete Nonces sind ungeeignet; bei zwischengespeichertem HTML kommen beispielsweise Hashes oder eine konsistente Neuerzeugung von Header und HTML infrage.

Nonces gelten nicht für Ereignisattribute wie onclick. Hashes benötigen dafür zusätzlich 'unsafe-hashes'; Ereignisbehandlung in Skripten ist meist leichter abzusichern. Content-Security-Policy-Report-Only hilft bei der Erprobung und meldet Verstöße, blockiert aber nicht nach dieser Policy.

HSTS: Laufzeit, HTTPS und vollständige Domainabdeckung

max-age legt die Speicherdauer in Sekunden fest. Eine gültige HSTS-Antwort über fehlerfreies HTTPS erneuert die Frist. Während der Gültigkeit ersetzt der Browser HTTP-Aufrufe des betroffenen Hosts durch HTTPS. Über unverschlüsseltes HTTP empfangene HSTS-Header werden ignoriert.

max-age=300 schützt fünf Minuten und kann als kontrollierte Einführungsstufe sinnvoll sein. Für dauerhaftes HTTPS sind längere Fristen üblich. includeSubDomains setzt zuverlässiges HTTPS auch auf allen betroffenen Unterdomains voraus, einschließlich interner Systeme.

Das Schlüsselwort preload allein trägt keine Domain in Browserlisten ein. Dafür sind ein eigener Aufnahmeprozess, die Voraussetzungen der Liste und die Verteilung an Browser nötig. Die offizielle Preload-Seite empfiehlt derzeit HSTS, aber keine allgemeine Vorabaufnahme mehr. Eine bestehende Aufnahme lässt sich nicht sofort durch Entfernen des Schlüsselworts rückgängig machen.

Frame-Schutz: Nur eine durchgesetzte Policy hat Vorrang

X-Frame-Options: DENY untersagt Frames, SAMEORIGIN begrenzt die Einbettung auf dieselbe Origin. In unterstützenden Browsern hat frame-ancestors aus einer durchgesetzten CSP Vorrang vor X-Frame-Options. Ein Report-Only-Header hebt X-Frame-Options nicht auf.

frame-ancestors * erlaubt insbesondere gewöhnliche HTTP(S)-Origins sehr weitgehend; das daneben gesetzte DENY rettet diese Konfiguration nicht. Mehrere durchgesetzte CSPs gelten gleichzeitig. Für verbotene Einbettung eignet sich eine konsistente Kombination aus frame-ancestors 'none' und X-Frame-Options: DENY als Kompatibilitätsrückfall.

Referrer: Origin ist mehr als eine Domain

strict-origin-when-cross-origin übermittelt bei derselben Origin grundsätzlich die Adresse einschließlich Pfad und Abfrageparametern. Bei einem Wechsel der Origin bleibt normalerweise nur Schema, Host und gegebenenfalls Port; beim Wechsel von HTTPS zu unsicherem HTTP entfällt der Referrer. Verschiedene Subdomains oder Ports sind bereits verschiedene Origins.

unsafe-url kann Pfad und Abfrageparameter auch an andere Origins und über HTTP weitergeben. URL-Fragmente nach # und Zugangsdaten werden nicht als Referrer übertragen. no-referrer unterdrückt den Referrer. Zusätzliche Regeln am Link, Browserpräferenzen oder Erweiterungen können die tatsächliche Ausgabe beeinflussen. Sensible Daten gehören möglichst nicht in URLs.

Eine Momentaufnahme ersetzt keinen Browsertest

Der HTTP-Security-Header-Prüfer ruft eine öffentliche Adresse einschließlich begrenzter HTTP-Weiterleitungen ab und bewertet die letzte Antwort mit vereinfachten Regeln. Die Auswertung ist kein vollständiges Browsermodell: Mehrfachheader, Nonces, speziellere CSP-Direktiven und Report-Only-Konstellationen benötigen eine zusätzliche Prüfung.

Maßgeblich sind die tatsächlich ausgelieferten Antworten relevanter Seiten, Fehlerseiten und Anmeldestatus sowie die beobachtete Wirkung im Browser. Weiterleitungen erzeugen mehrere Anfragen. JavaScript-Navigationen, Meta-Regeln und benötigte Anwendungsfunktionen werden durch eine reine Headeraufnahme nicht vollständig geprüft.