HTTP-Header prüfen: Status, Weiterleitungen und die Header, die zählen
Ein HTTP-Header-Check zeigt Statuscode, Weiterleitungskette und fehlende Security-Header. So prüfst du HTTP-Header, ohne dich auf ein Browser-Plugin zu verlassen.
Ein HTTP-Header-Check ist das rohe Gespräch zwischen Client und Server, vor jedem Rendering. Gesucht wird er als „http header check“, „check http headers“, „server header checker“ und „http headers online“. Gemeint ist dasselbe: die Statuszeile, jeder Antwort-Header und der Weg, den eine Weiterleitung genommen hat.
Was ein Server-Header-Check zeigen sollte
- Den endgültigen Statuscode und die URL, zu der er gehört — nach den Weiterleitungen. Der erste Hop ist oft eine 301, die über die Seite nichts sagt.
- Jeden Weiterleitungs-Hop: URL, Status und das Location-Ziel. Nur so sieht man eine Schleife oder einen versehentlichen Rückfall auf http://.
- Die Antwort-Header, wie der Server sie geschickt hat. Die Entwicklertools des Browsers zeigen dieselben Bytes, vermischt mit Headern, die deine Erweiterungen dazugepackt haben.
- Ob das TLS-Zertifikat vertrauenswürdig war. Eine Header-Liste von einer https-URL, deren Handshake nie zu Ende ging, ist keine Header-Liste.
Der Header-Checker auf dieser Website macht das von Zürich aus, für eine öffentliche http://- oder https://-URL. Er liest keinen Antwort-Body. Ein Browser-Plugin, das Skripte einsetzt, wird nicht bei jedem Header mit ihm übereinstimmen — und genau dieser Unterschied ist der Grund, von außerhalb des Browsers zu prüfen.
HTTP-Header prüfen, die Sicherheit verändern — nicht nur das Debugging
Die meisten Header sind informativ. Eine kurze Liste verdient ein bewusstes Ja oder Nein, weil ihr Fehlen verändert, was ein Browser tut. Fehlen ist nicht automatisch ein Mangel. Es ist eine Entscheidung, von der du wissen solltest, dass du sie getroffen hast.
| Header | Wenn er fehlt |
|---|---|
| Strict-Transport-Security | Ein Browser kann bei einem späteren Besuch zuerst http:// versuchen. In Ordnung nur, wenn die Seite nicht ausschließlich https ist. |
| Content-Security-Policy | Nichts schränkt ein, woher Skripte und Styles geladen werden dürfen. |
| X-Content-Type-Options | Browser dürfen den Typ einer Antwort raten, statt dem angegebenen zu vertrauen. |
| X-Frame-Options | Eine andere Seite kann diese Seite einrahmen, sofern eine CSP-Frame-Regel das nicht schon abdeckt. |
| Referrer-Policy | Volle URLs, inklusive Query-String, können an andere Seiten gehen, wenn ein Besucher einem Link folgt. |
Server-Header und das, was der Browser anzeigt
Die Entwicklertools sind das richtige Werkzeug für einen Header, den deine eigene Sitzung gesetzt hat: ein Cookie, ein Authorization-Wert, ein Anfrage-Body. Sie sind das falsche Werkzeug für die Frage „was bekommt ein anonymer Client?“. Antworten im eingeloggten Zustand, gecachte 304 und von Erweiterungen gesetzte Content-Security-Policies zeichnen ein schiefes Bild der öffentlichen Seite. Eine Online-Prüfung schickt keine Cookies und keine Erweiterungen mit.
Server und X-Powered-By lohnen sich aus einem anderen Grund. Sie nennen Software. Das hilft später, wenn du wissen willst, ob eine veröffentlichte Schwachstelle zu der Version passt, die du betreibst — und es ist zugleich eine Information, die du vielleicht nicht ausschreiben möchtest. Der Header-Check zeigt sie. Er schaltet sie nicht ab.
curl -fsS https://api.hypermonitors.com/v1/tools/http \
-H 'content-type: application/json' \
-d '{"url":"https://example.com"}'Das JSON enthält finalUrl, status, headers, redirects und eine Zertifikats-Zusammenfassung, wenn die URL https war. Dieselben Grenzen wie beim Status-Checker: öffentliche Hosts, nur Header, mit Rate-Limit. Ein HTTP-Monitor vergleicht diese Header nicht. Er folgt Weiterleitungen standardmäßig und wertet 200–399 als erreichbar, sofern du nicht selbst festlegst, welche Statuscodes gesund sind. Ein Security-Header kann verschwinden, und der Monitor bleibt grün. Führ den Checker erneut aus, wenn sich die Server-Konfiguration ändert.