Sechs von sechs Headern vorhanden. Das klingt beruhigend – ungefähr wie „alle Türen eingebaut“. Ob eine Tür auch schließt, ist damit noch nicht gesagt. Bei Security-Headern zählt deshalb nicht nur der Name, sondern die tatsächlich ausgelieferte Regel.

Security-Header sind HTTP-Antwort-Header, mit denen ein Server dem Browser zusätzliche Vorgaben übermittelt. Sie erscheinen nicht als sichtbarer Seiteninhalt. Besucher bemerken sie meist erst indirekt: Eine unerwünschte Einbettung wird verhindert, eine Verbindung auf HTTPS festgelegt oder ein fremdes Skript blockiert.

Warum ein Header-Check kein Gütesiegel ist

Ein Header kann vorhanden, aber wirkungslos oder ungeeignet sein. Eine zu großzügige Regel schützt möglicherweise kaum; eine unpassend strenge kann legitime Funktionen beschädigen. Ebenso können unterschiedliche Seiten, Subdomains oder Antworten verschiedene Header liefern.

Prüfen Sie deshalb nicht nur eine Konfigurationsdatei auf dem Server. Relevant ist, was nach Weiterleitungen, Proxy und CDN tatsächlich beim Browser ankommt. Ein Hosting-Wechsel kann diese Ausgabe verändern, obwohl die Anwendung selbst unverändert geblieben ist.

Auch ein sehr gutes Ergebnis in diesem Teilbereich sagt nichts Abschließendes über unsichere Plugins, Berechtigungen, Backups oder sämtliche Anwendungslücken aus. Ein Security-Header-Check ist ein Baustein der technischen Pflege, kein Penetrationstest.

Strict-Transport-Security: HTTPS nicht dem Zufall überlassen

Strict-Transport-Security, kurz HSTS, teilt dem Browser mit, den betreffenden Host für eine bestimmte Zeit nur über HTTPS anzusprechen. Der Browser merkt sich diese Vorgabe nach dem Empfang über eine sichere Verbindung. Eine gewöhnliche HTTP-Weiterleitung und HSTS sind daher nicht dasselbe. Die Details erklärt MDN zu Strict-Transport-Security.

Die Einstellung muss zur Infrastruktur passen. Wer Subdomains einschließt, sollte wissen, welche davon existieren und ob sie zuverlässig HTTPS anbieten. Ein auf gut Glück kopiertes Beispiel ist hier keine Wartungsstrategie. Auch eine lange Gültigkeit sollte bewusst gewählt werden, weil der Browser die Regel nicht nach dem nächsten Seitenaufruf vergisst.

Content-Security-Policy: Welche Inhalte dürfen woher kommen?

Eine Content-Security-Policy, kurz CSP, kann festlegen, aus welchen Quellen bestimmte Inhalte geladen oder welche Skripte ausgeführt werden dürfen. Sie ist besonders interessant, weil sie über „Header vorhanden“ hinaus viele unterschiedliche Regeln enthalten kann. Ein sehr offener Wert ist nicht dasselbe wie eine sorgfältig abgestimmte Richtlinie. Quelle: MDN zu Content-Security-Policy.

Ein Beispiel aus dem Arbeitsalltag: Nach einer Änderung funktioniert die eingebettete Terminbuchung nicht mehr. Das muss kein defekter Link sein. Möglicherweise blockiert eine CSP die notwendige Einbettung. Umgekehrt sollte die Lösung nicht reflexartig darin bestehen, alle Quellen freizugeben. Erst muss die konkrete Blockierung verstanden werden.

Für eine Einführung oder Verschärfung eignet sich häufig ein kontrollierter Testprozess mit einer zunächst beobachtenden Content-Security-Policy-Report-Only. Diese meldet Verstöße, erzwingt die Richtlinie aber nicht. Sie darf deshalb nicht mit einer aktiv schützenden CSP verwechselt werden. Siehe MDN zur Report-Only-Variante.

Weitere Header, verständlich übersetzt

X-Content-Type-Options: Mit dem Wert nosniff kann der Browser angewiesen werden, bestimmte Inhalte nicht entgegen ihrem deklarierten Typ zu interpretieren. Passende Content-Type-Angaben bleiben trotzdem nötig. Technische Beschreibung.

X-Frame-Options: Dieser Header beschränkt die Einbettung einer Seite in Frames und kann gegen bestimmte Clickjacking-Szenarien helfen. Bei modernen Richtlinien spielt zusätzlich die CSP-Direktive frame-ancestors eine Rolle. Die gewünschte Einbettung eigener Inhalte muss dabei berücksichtigt werden. Technische Beschreibung.

Referrer-Policy: Hier wird gesteuert, welche Herkunftsinformation der Browser bei Anfragen weitergibt. Das ist etwas anderes als eine allgemeine Verhinderung externer Verbindungen. Technische Beschreibung.

Diese kurzen Erklärungen sind eine Orientierung für die Übergabe an Hosting oder Entwicklung. Sie sind keine universelle Konfiguration zum Einfügen. Welche Werte passen, hängt von Ihren Inhalten, Einbindungen und Anforderungen ab.

Mehr Header sind nicht automatisch besser

Im Netz kursieren lange Checklisten, die jeden fehlenden Header als Mangel zählen. Manche Einträge sind veraltet. Ein Beispiel ist X-XSS-Protection: MDN kennzeichnet den Header als veraltet und weist auf mögliche unerwünschte Folgen hin. Sein Fehlen sollte deshalb nicht ohne Kontext als fehlender moderner Schutz bewertet werden. Quelle: MDN zu X-XSS-Protection.

Ein nachvollziehbarer Prüfbericht trennt daher zwischen der Anzahl vorhandener Header, der Bewertung ihrer Werte und offenen Konfigurationshinweisen. „6 von 6 gesetzt“ kann neben einem Hinweis auf eine zu offene CSP stehen. Die erste Aussage zählt; die zweite bewertet einen konkreten Inhalt. Beides muss verständlich beschriftet sein.

So geben Sie den Befund sinnvoll weiter

Übermitteln Sie die betroffene URL, den Zeitpunkt, den beobachteten Header und den konkreten Hinweis. Die zuständige Person kann dann prüfen, ob die Ursache im Webserver, im Proxy, im CDN oder in der Anwendung liegt. „Bitte alles auf A stellen“ ist dafür kein guter Auftrag.

Nach der Änderung testen Sie auch die wichtigen Funktionen: Formulare, Buchung, Videos, Shop und Administrationszugänge. Gute Schutzregeln sollen unerwünschte Vorgänge begrenzen, nicht still den gewünschten Bestellweg abschalten. Werden Regeln zunächst nur beobachtet, gehört auch der spätere Schritt zur Durchsetzung in den Arbeitsplan.

Verbinden Sie diese Prüfung mit Ihrer regelmäßigen Website-Wartung. Und wenn ein fremder Dienst überraschend blockiert wird, klären Sie gleichzeitig, warum er überhaupt geladen wird.