HTTP-Header-Analyzer
Prüft ausgelieferte Header, Redirect-Schritte, Cookies, Isolation sowie doppelte oder widersprüchliche Felder.
Web-SicherheitSecurity-Header, die das Risiko wirklich verändern
Eine lange Header-Liste ist noch kein Sicherheitskonzept. Wirksam sind Policies, deren Fehlerbild du verstehst, für die es einen klaren Besitzer gibt und deren ausgelieferter Wert jede CDN-, Proxy-, Redirect- und Applikationsschicht bis zum Browser überlebt.
Entscheidend ist die Antwort am Browser
Security-Header sind schnell konfiguriert und noch schneller falsch beurteilt. Am Origin kann alles sauber aussehen, während draußen etwas anderes ankommt: Das CDN hängt eine zweite Content-Security-Policy an, der Loadbalancer entfernt Strict-Transport-Security auf Redirects oder eine einzelne Applikationsroute überschreibt die Plattformvorgabe. Der Browser wertet weder dein Terraform noch das nginx-Template oder die Middleware aus. Er verarbeitet die letzte HTTP-Antwort — Statuscode für Statuscode, Hostname für Hostname. Dazu gehören auch Antworten, die selten jemand manuell öffnet: ein 404 mit reflektierter Eingabe, ein 500 aus dem Fehler-Frontend oder ein Download von einem getrennten Asset-Host. Gerade Nebenpfade fallen zuerst aus zentralen Vorgaben heraus.
Prüfe deshalb von außen und bewahre die Rohdaten auf. Der HTTP-Header-Analyzer ordnet Befunde zu Sicherheit, Cache, Cookies, Framing und Isolation, erfasst bei öffentlichen URLs eine kurze Redirect-Kette und hebt doppelte oder widersprüchliche Felder hervor. Für interne Dienste fügst du aufgezeichnete Header ein. Teste HTML, APIs, Fehlerseiten, Login-Callbacks, Downloads und Redirects getrennt; der perfekte Header auf der Startseite sagt nichts über die Antwort aus, die tatsächlich Sitzungsdaten verarbeitet.
CSP ist ein Applikationsprojekt, keine Konfigurationszeile
Die Content Security Policy hat enorme Wirkung — und eine besonders schlechte Rollout-Kultur. Eine kopierte Policy mit default-src 'self' wirkt streng, bis Inline-Bootstrap, Analytics, Uploads, Worker, Frames und Zahlungsanbieter auf sie treffen. Dann folgen 'unsafe-inline', großzügige Wildcards und komplette CDN-Domains, bis die Seite wieder läuft. Übrig bleibt eine dekorative CSP: formal vorhanden, praktisch unfähig, genau jene Script-Injection einzudämmen, für die sie gedacht war.
Baue die Policy aus einem Inventar realer Ausführungs- und Datenflüsse. Starte mit Content-Security-Policy-Report-Only, sammle Verstöße mit Route und Release-Kontext und entferne zufällige Abhängigkeiten, statt sie reflexartig freizuschalten. Verwende Nonces oder Hashes für bewusstes Inline-Script, setze object-src 'none', solange keine Altanwendung das Gegenteil beweist, und definiere base-uri sowie frame-ancestors ausdrücklich. Report-only ist ein Migrationswerkzeug, kein Zielzustand: Erzwinge früh eine brauchbare Basis und verschärfe sie in messbaren Schritten. CSP gehört in Applikationstests, denn die Applikation weiß, was ausführen muss.
HSTS wird erst mit großer Reichweite gefährlich
Strict-Transport-Security weist einen Browser, der HTTPS bereits erreicht hat, für künftige Verbindungen auf HTTPS fest. Eine produktive Site braucht in der Regel eine deutliche max-age, doch der Einstieg sollte kurz sein: klein beginnen, Fehler beobachten, dann verlängern. includeSubDomains ist kein Reifegrad-Abzeichen, sondern ein Versprechen für jeden heutigen und künftigen Unterhost — einschließlich Anbieterportalen, vergessener Appliances, delegierter Zonen und temporärer Kampagnendomains.
Preload verankert dieses Versprechen bereits im Browser und schließt damit die erste Klartextverbindung, macht einen Rückweg aber langsam und schmerzhaft. Beantrage es erst nach vollständigem Subdomain-Inventar, sauberen Redirects, erprobter Zertifikatsautomatisierung und einer bewusst akzeptierten Austragungsfrist. Den Transport selbst prüfst du mit der TLS-Konfigurationsprüfung: Sie meldet Protokollunterstützung, Namensabgleich des Zertifikats, ALPN, SNI-Verhalten, HSTS-Evidenz und grobe Schwachstellenklassen. HSTS rettet weder ein abgelaufenes Zertifikat noch einen Host, der nie HTTPS konnte.
Die kleinen Kontrollen schließen echte Türen
X-Content-Type-Options: nosniff ist unspektakulär und fast immer sinnvoll. Der Browser soll deklarierte Script- und Stylesheet-Typen nicht umdeuten; aus korrektem Content-Type wird damit eine Grenze statt eines Hinweises. Falsche MIME-Typen repariert der Header nicht. Rolle ihn mit korrekten Metadaten aus und teste Downloads, Altbestände und dynamisch erzeugte Dateien. Für Framing ist CSP frame-ancestors die präzisere Wahl; X-Frame-Options kann für ältere Clients bleiben, darf aber nicht als zweite, widersprüchliche Policy verwildern.
Cookies verlangen dieselbe Genauigkeit. Secure verhindert Klartextübertragung, HttpOnly entzieht das Cookie dem Script-Zugriff und SameSite begrenzt das Senden aus fremden Sites. Keine Eigenschaft ersetzt die andere. Ein Session-Cookie braucht meist alle drei, während OAuth- oder Federation-Callbacks ein eng gefasstes SameSite=None; Secure erfordern können. Lass Domain für Host-only-Cookies weg, halte Path klein und verwende für hochwertige, hostgebundene Cookies das Präfix __Host-. Gute Flags reduzieren Angriffsfläche; harmlos machen sie XSS nicht.
Isolation verändert das Ökosystem der Seite
Cross-Origin-Opener-Policy und Cross-Origin-Embedder-Policy können ein Dokument in einen cross-origin-isolierten Browserkontext bringen. Das schützt Fensterbeziehungen und ermöglicht Fähigkeiten wie SharedArrayBuffer. Es ist eine echte Grenze, kein pauschaler Härtegrad. COOP: same-origin kann Popup-basierte Logins und Zahlungen stören; COEP: require-corp blockiert fremde Ressourcen, wenn sie nicht über CORS oder Cross-Origin-Resource-Policy mitspielen. Eine einzige unkooperative Schrift, Grafik, Worker- oder Vendor-Datei kann die Route brechen.
Rolle Isolation deshalb pro Route und Abhängigkeitsgraph aus. Erfasse jeden eingebetteten Ursprung, teste Opener- und Popup-Verhalten und kläre, ob die jeweiligen Betreiber passende CORS- oder CORP-Signale liefern können. COEP: credentialless kann bei geeigneter Browserbasis helfen, verändert aber den Umgang mit Credentials und braucht ebenfalls Kompatibilitätstests. Wenn deine Anwendung keine Cross-Origin-Isolation benötigt, kaufst du dir mit den Headern vor allem eine Wartungspflicht. Eine Policy ohne Verbraucher und Test ist ein späterer Ausfall mit offenem Termin.
Ein Schreiber, jeder Pfad unter Beobachtung
Doppelte Felder verraten ungeklärte Zuständigkeit. Manche Header werden über Zeilen kombiniert, manche faktisch ausgewählt, andere durch Anhängen ungültig oder unerwartet streng. Zwei CSP-Felder werden beide erzwungen; ihre Schnittmenge kann Inhalte blockieren, obwohl jede Schicht ihre eigene Policy für korrekt hält. Mehrere HSTS-Werte, gegensätzliches Framing oder wiederholte Cookie-Manipulationen zeigen, dass CDN und Origin dieselbe Antwort unabhängig regieren.
Bestimme pro Policy eine autoritative Schicht, dokumentiere Ausnahmen und lass nachgelagerte Systeme gezielt ersetzen statt anhängen. Prüfe die kanonische URL und alle weiterleitenden Hosts mit der Redirect-/Canonical-/Indexierbarkeitsprüfung, um Redirect- und Zielverhalten offenzulegen, und inspiziere anschließend jede einzelne Antwort. Regressionstests gehören in CI, ein öffentlicher Probe-Job bleibt trotzdem nötig: Korrekte Konfiguration vor dem Rollout und wirksames Verhalten danach sind zwei verschiedene Tatsachen. Nur die zweite erreicht deine Nutzer. Versioniere erwartete Werte pro Route und alarmiere auf Abweichungen, nicht pauschal auf das Fehlen einer maximalen Wunschliste. So bleibt ein bewusst anderer API-Header von einem echten Verlust unterscheidbar.