HTTP-Header-Checker
Zeigt die HTTP-Antwort-Header und die Weiterleitungskette jeder URL, mit einer Prüfung der Sicherheits-Header.
HTTP-Header-Checker wird geladen… Wenn nichts passiert, aktiviere JavaScript.
Jede Web-Antwort beginnt mit einem Block HTTP-Header, den Besucher nie sehen: der Statuscode, wohin eine Weiterleitung zeigt, wie lange die Seite zwischengespeichert werden darf, welcher Inhaltstyp vorliegt und eine Reihe von Sicherheitsanweisungen für den Browser. Die meisten SEO-, Performance- und Sicherheitsprobleme hinterlassen dort ihre erste Spur: eine Weiterleitungsschleife, ein 302, das ein 301 sein sollte, ein fehlender HSTS-Header, ein CDN, das nicht cachen will. Dieses Tool ruft eine URL von unserem Server aus ab und zeigt die Header genau so, wie sie ankommen.
Beispiele
http://github.com
301 → https://github.com/ → 200
Eine Weiterleitung von HTTP auf HTTPS, danach die endgültige Seite mit gesetztem HSTS, CSP und X-Frame-Options.
Cache-Control: max-age=0, private, must-revalidate
Stored, but revalidated with the server on every use (browser only, not CDNs).
Die Cache-Zusammenfassung übersetzt die Direktiven in verständliche Sprache.
Häufig gestellte Fragen
Was ist der Unterschied zwischen einer 301- und einer 302-Weiterleitung?
Wie viele Weiterleitungen sind zu viele?
Welche Sicherheits-Header sind am wichtigsten?
Warum sehe ich andere Header als in den Entwicklertools meines Browsers?
Warum zeigt das Tool GET statt HEAD an?
Kann ich eine Seite auf localhost oder im internen Netz prüfen?
Prüft das Tool das TLS-Zertifikat?
Werden die geprüften URLs gespeichert?
Über HTTP-Header-Checker
Füge eine URL ein, und der Checker fragt sie wie ein Browser ab, ohne Weiterleitungen automatisch zu folgen. Jeder Sprung erscheint der Reihe nach mit Statuscode, Antwortzeit und vollständiger Header-Liste. So siehst du den ganzen Weg von http://example.com bis zum endgültigen https://www.example.com/ und erkennst überflüssige Sprünge, die den ersten Besuch verlangsamen. Klicke auf einen Sprung, um seine Header zu sehen, filtere sie nach Name oder Wert und kopiere sie als Rohtext.
Die endgültige Antwort bekommt eine Prüfung der Sicherheits-Header. Das Tool prüft Strict-Transport-Security (samt max-age), Content-Security-Policy (und ob sie noch unsafe-inline-Skripte erlaubt), X-Frame-Options oder CSP frame-ancestors gegen Clickjacking, X-Content-Type-Options, Referrer-Policy, Permissions-Policy und Cross-Origin-Opener-Policy und weist auf Header hin, die Softwareversionen des Servers verraten. Jeder Punkt erklärt verständlich, was der Header bewirkt und was fehlt. Ein eigener Abschnitt übersetzt Cache-Control, Expires, ETag, Age und Vary in eine einzeilige Antwort darauf, wie die Seite gecacht wird.
Die Anfragen kommen von unserem Server, du siehst also die öffentliche Antwort und nicht das, was dein Browser oder ein lokaler Proxy sendet. Zuerst wird eine HEAD-Anfrage versucht, und wenn der Server HEAD ablehnt, ein GET, das abbricht, sobald die Header da sind, damit kein Seiteninhalt heruntergeladen wird. Erlaubt sind nur http und https auf den Ports 80, 443, 8080 und 8443, jedes Weiterleitungsziel wird erneut geprüft, und private oder interne Adressen sind gesperrt.
Header, die ihren Zweck überlebt haben
HTTP-Header sammeln Geschichte an. Der Header Referer ist falsch geschrieben, weil Phillip Hallam-Baker ihn im Entwurf aus den 90er-Jahren mit nur einem „r“ schrieb, und als es jemand bemerkte, hingen bereits überall Server davon ab. Der neuere Header Referrer-Policy ist korrekt geschrieben, also trägt das Web heute beide Schreibweisen nebeneinander.
X-XSS-Protection ist ein Header, der später absichtlich abgeschaltet wurde. Der Internet Explorer 8 führte 2008 einen XSS-Filter ein, Chrome zog nach, doch Forscher zeigten, dass sich der Filter selbst missbrauchen ließ, um Daten abzugreifen oder legitime Skripte zu deaktivieren. Chrome entfernte seinen XSS Auditor 2019, und der empfohlene Wert ist heute 0 oder gar kein Header, die eigentliche Arbeit übernimmt Content-Security-Policy.
Das X-Präfix selbst wurde 2012 durch RFC 6648 offiziell für veraltet erklärt. Die Idee war, dass experimentelle Header X- tragen und es bei der Standardisierung ablegen, aber beliebte Header wie X-Forwarded-For und X-Frame-Options haben das Präfix nie verloren, weil eine Umbenennung nur Dinge kaputt gemacht hätte. Neue Header werden heute von Anfang an ohne Präfix registriert.