Eingaben
Beispiel
Füge Header aus curl ein oder rufe https://example.com ab, um CSP, HSTS, X-Content-Type-Options, Cookies und Cache-Policy zu prüfen.
HTTP-Header-Analyzer
Analysiert eingefügte HTTP-Response-Header lokal oder ruft Header für eine öffentliche URL über den eingeschränkten Endpunkt ab.
Gut für CSP, HSTS, Cookies, Cache-Verhalten, Framing-Policy und Content-Type-Signale ohne vollständigen Scan.
Header sind deine Sicherheitsrichtlinie unterwegs
Fast alles, was ein Browser über den Umgang mit einer Site erfährt, reist in Response-Headern: ob Transportsicherheit verpflichtend ist, welcher Inhalt ausgeführt werden darf, ob die Seite geframt werden darf, wie Cookies gescoped sind, wie lange Caches eine Antwort halten dürfen. Das macht Header zur schnellsten ehrlichen Audit-Fläche überhaupt — und zugleich zu einem Ort, an dem Policies leise verrotten, denn ein in einer Debugging-Session entfernter oder von einer zweiten Proxy-Schicht duplizierter Header kündigt sich selten an.
Dieser Analyzer liest ein Response-Header-Set und ordnet es in praktische Gruppen: Security-Header, Caching, Content-Typing, Cookies, Isolations- und Framing-Policy. Er markiert, was fehlt, was sich widerspricht und was doppelt vorkommt — der Duplikatfall zählt mehr, als man erwartet: Wenn CDN und Origin denselben Header setzen, ist das, was der Browser durchsetzt, womöglich keiner der beiden beabsichtigten Werte.
Von der Rohantwort zu priorisierten Befunden
Füge Header ein, wenn du sie schon hast — aus curl, den Browser-Developer-Tools oder einem Proxy —, denn das hält die Analyse vollständig lokal und funktioniert auch für Antworten, die das öffentliche Internet nicht erreichen kann. Nutze den Live-Fetch für die Außensicht auf eine öffentliche URL: Er protokolliert auch Redirect-Kette und finale URL, wo die interessanten Überraschungen oft wohnen — jeder Hop einer Redirect-Kette trägt sein eigenes Header-Set.
Arbeite die Befunde nach Hebelwirkung ab. Zuerst Transport- und Ausführungspolicy: HSTS und Content-Security-Policy entscheiden ganze Angriffsklassen. Dann Cookie-Attribute und Framing, danach Cache-Korrektheit — falsch gecachter personalisierter Inhalt ist ein Sicherheitsvorfall im Performance-Kostüm. Nimm Warnungen als Prüfimpulse, nicht als Urteile, und fahre nach jedem Fix erneut gegen die deployte Site: Header-Änderungen bestehen gern das Review und werden dann auf dem Weg zur Produktion von einer Middlebox verschluckt.
Fetch-Guards und Analysegrenzen
Eingefügte Header bleiben im Browser. Live-Abrufe laufen über /api/http-headers.php: nur vollständige http- oder https-URLs auf den Ports 80 und 443, keine eingebetteten Zugangsdaten, private, Loopback-, Link-Local-, Multicast- und reservierte aufgelöste Adressen werden blockiert, eine kleine Redirect-Kette wird verfolgt, kein Request-Body gesendet. Der Analyzer bewertet Response-Header — er parst keinen Seiteninhalt, führt keine Skripte aus und ersetzt keinen vollständigen Schwachstellenscan; Header-Policy wird immer gegen den Bedarf der konkreten Anwendung beurteilt.
Häufige Fragen
Warum nicht jede URL direkt aus dem Browser abrufen?
Weil CORS gezielt verhindert, dass eine Seite Response-Header beliebiger fremder Sites liest. Der Same-Origin-Endpunkt führt auf deine Anforderung genau einen geschützten Abruf aus und liefert die Header zur lokalen Analyse zurück.
Bedeutet eine Warnung, dass die Site unsicher ist?
Nicht automatisch. Header-Policy ist anwendungsabhängig — eine API antwortet anders als eine HTML-Seite, ein Intranet-Tool anders als ein Shop. Eine Warnung markiert eine prüfenswerte Entscheidung, keinen bewiesenen Defekt.
Warum bekommen doppelte Header eigene Befunde?
Weil sie meist ein Symptom geschichteter Infrastruktur sind — CDN, Load Balancer, Origin — die jeweils eigene Policy setzen. Browser lösen Duplikate je nach Header unterschiedlich auf; die effektive Policy kann still von der Absicht jeder einzelnen Schicht abweichen.
Was prüfe ich auf einer typischen Site zuerst?
Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options und die Cookie-Attribute. Diese vier entscheiden die größten Angriffsklassen; die meisten übrigen Befunde sind Verfeinerung obendrauf.
Kann der Live-Fetch interne URLs scannen?
Nein. Der Endpunkt verlangt öffentliche DNS-Namen und blockiert private und reservierte aufgelöste Adressen. Für interne Systeme: Header dort erfassen und den Paste-Pfad nutzen — die Analyse ist identisch.
Warum zählt die Redirect-Kette für ein Header-Audit?
Weil jeder Hop eine eigene Antwort mit eigenen Headern ist und Schutz, der auf einem frühen Hop fehlt, für echte Nutzer fehlt. Ein HSTS-Header nur auf der finalen HTTPS-Antwort, aber nicht auf den umleitenden Hosts, ist die klassische Lücke, die diese Sicht aufdeckt.