HTTP-Header-Prüfer

Ein HTTP-Header-Prüfer ruft eine URL ab und zeigt die Antwort-Header, die der Server zurückschickt: den Statuscode, die Cache- und Cookie-Felder und die Sicherheits-Header, die der Browser durchsetzt. Dieses Werkzeug ergänzt eine Bewertung von 0 bis 100 aus sieben davon: HSTS, CSP, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy und Permissions-Policy. Für github.com kommen 200 OK in rund 60 ms, 17 Header und 90/100 mit der Note A+ zurück.

🌐
Testen:

Was zeigt dieser HTTP-Header-Prüfer an?

Geben Sie eine Domain ein: Das Werkzeug schickt von unserem Server eine HEAD-Anfrage an diese Adresse und zeigt anschließend den Statuscode, die Umlaufzeit in Millisekunden, die vollständige Liste der Antwort-Header und eine Sicherheitsbewertung von 0 bis 100 aus HSTS, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy und Permissions-Policy. Es meldet, was der Server gesendet hat: Weiterleitungen folgt es nicht, und den Seiteninhalt liest es nicht.

Dieses Tool in Ihre Website einbetten

× px

                        

💡 Integrations-Tipp

Kopieren Sie den Einbettungscode und fügen Sie ihn in das HTML Ihrer Website ein. Die responsive Version passt sich automatisch an alle Bildschirmgrößen an.

0 Bewertungen
✓

Beliebte Werkzeuge

Keine weiteren Tools
Alle Tools erkunden

Lautet der Status 3xx, leitet die Seite weiter: Verfolgen Sie mit dem Weiterleitungs-Prüfer jeden einzelnen Hop, um herauszufinden, wo die URL schließlich landet.

Über HTTP-Header-Prüfer

Dieser HTTP-Header-Prüfer nimmt eine URL, schickt von unserem Server eine HEAD-Anfrage dorthin und zeigt, was zurückkommt: den Statuscode samt Statustext, die Umlaufzeit in Millisekunden und jeden Antwort-Header, den der Server gesendet hat. Für github.com sind das 200 OK in rund 60 ms und 17 Header-Felder, von content-type und etag bis zum vollständigen Wert von content-security-policy.

Die Karte Sicherheitsbewertung benotet sieben Header auf einer Skala bis 100. Strict-Transport-Security und Content-Security-Policy zählen je 20 Punkte, X-Content-Type-Options und X-Frame-Options je 15, X-XSS-Protection, Referrer-Policy und Permissions-Policy je 10. Ab 90 Punkten steht dort A+, ab 80 A, ab 70 B, ab 60 C, ab 40 D, darunter F. github.com erreicht 90/100, weil Permissions-Policy fehlt; example.com sendet keinen der sieben und erreicht 0.

Gezählt wird das Vorhandensein, nicht die Qualität. Der Wert x-xss-protection: 0 schaltet diesen Filter ab und bringt trotzdem seine zehn Punkte, ein content-security-policy-report-only dagegen keinen einzigen. Lesen Sie deshalb die Werte unter jeder mit Present markierten Zeile und nicht nur die Note. Weiterleitungen werden nicht verfolgt: google.com antwortet mit 301 und location: https://www.google.com/, und erst wenn Sie diese Adresse einsetzen, wird das Ziel bewertet. Die Anfrage ist eine reine HEAD-Anfrage, also werden weder HTML noch Meta-Tags noch Seitentext ausgewertet; nach zehn Sekunden bricht sie ab, und pro Adresse werden zwanzig Prüfungen je Minute angenommen.

Die eingegebene URL geht an den Server dieser Website, der die Anfrage für Sie stellt – mit der Kennung FreeWebTools Header Checker/1.0 und ohne Ihre Cookies oder Sitzung. Sie sehen also, was ein anonymer Besucher erhält. Private und reservierte IP-Bereiche, localhost, Cloud-Metadaten-Endpunkte und Verwaltungsports wie 22, 3306 und 6379 werden abgelehnt.

Anwendungsfälle

Eine Entwicklerin, die eine Content-Security-Policy ausrollt, prüft nach jedem Deployment die Staging-Domain und bestätigt, dass wirklich content-security-policy erscheint und nicht nur content-security-policy-report-only, das die Bewertung bewusst ignoriert.
Ein SEO, der eine Domain-Migration abnimmt, fügt eine alte URL ein, liest den 301 und den zurückgegebenen location-Wert und setzt dieses Ziel erneut ein, um die Kette Sprung für Sprung abzugehen – denn das Werkzeug folgt keiner Weiterleitung für Sie.
Ein Systemadministrator, der HSTS gerade aktiviert hat, prüft vor der Anmeldung zur Preload-Liste, dass strict-transport-security ein langes max-age sowie includeSubDomains und preload trägt; github.com liefert max-age=31536000; includeSubdomains; preload.
Ein Support-Techniker auf der Suche nach veralteten Inhalten liest cache-control, etag, age und cf-cache-status in der Tabelle Alle Antwort-Header, um Edge-Cache und Browser-Cache auseinanderzuhalten: example.com antwortet mit cf-cache-status: HIT und einem age von mehreren tausend Sekunden.
Eine Studentin, die HTTP lernt, klickt nacheinander die Beispiele google.com, github.com, cloudflare.com und stackoverflow.com an und vergleicht echte Header-Sätze und Noten von F bis A+ nebeneinander, ohne curl zu installieren oder die Entwicklertools zu öffnen.

So prüfen Sie die HTTP-Antwort-Header einer Website

1

Geben Sie eine Domain oder eine vollständige Adresse in das Suchfeld ein, zum Beispiel example.com; das Präfix https:// wird ergänzt. Sie können auch eines der Beispiele neben Testen anklicken: google.com, github.com, cloudflare.com oder stackoverflow.com.

2

Drücken Sie die Eingabetaste oder klicken Sie auf Prüfen. Die Anfrage verlässt unseren Server als HEAD-Anfrage, es kommen also nur die Header zurück, nie der Seiteninhalt.

3

Lesen Sie die drei Übersichtskarten: Statuscode mit Statustext, Sicherheitsbewertung von 100 samt Buchstabennote und Antwortzeit in Millisekunden.

4

Gehen Sie Sicherheits-Header durch und sehen Sie, welche von HSTS, CSP, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy und Permissions-Policy als Present oder Missing markiert sind, und lesen Sie den Wert unter jedem vorhandenen Header.

5

Öffnen Sie Alle Antwort-Header, um Name und Wert jedes vom Server gelieferten Headers zu lesen, auch die Cache-, Cookie- und CDN-Felder, die die Bewertung nicht abdeckt.

6

Klicken Sie auf Kopieren, um den gesamten Bericht – URL, Status, Bewertung mit Note und Header-Liste – als reinen Text in die Zwischenablage zu legen.

Profi-Tipps

  • Geben Sie nur die Domain ein: Das Feld ergänzt https:// selbst, github.com wird also als https://github.com geprüft. Schreiben Sie http:// ausdrücklich, um die Antwort über einfaches HTTP zu sehen – dort fehlt strict-transport-security meist, weil RFC 6797 den Browsern vorschreibt, den Header über eine unsichere Verbindung zu ignorieren.
  • Die Bewertung belohnt das Vorhandensein, nicht den Wert. github.com sendet x-xss-protection: 0 und schaltet den Filter damit ab, kassiert aber trotzdem die vollen zehn Punkte. Lesen Sie deshalb die graue Wertzeile unter jeder mit Present markierten Zeile, bevor Sie der Note trauen.
  • Eine Richtlinie im Report-only-Modus bringt keine Punkte. google.com sendet content-security-policy-report-only ohne durchgesetzte Richtlinie und verliert damit alle 20 CSP-Punkte; die Markierung Present erscheint nur beim exakten Header-Namen content-security-policy.
  • Zeigt die Karte Statuscode 301 oder 302, kopieren Sie den location-Wert aus der Header-Tabelle und starten Sie damit eine zweite Prüfung. Die Weiterleitungsantwort selbst trägt kaum Sicherheits-Header – deshalb landet google.com bei 25/100.
  • Die Schaltfläche Kopieren legt den ganzen Bericht als reinen Text in die Zwischenablage – URL, Status, Bewertung mit Note und jeden Header. Genau das fügen Sie in ein Ticket ein. Planen Sie Serienprüfungen mit zwanzig Abfragen pro Minute; darüber antwortet die Schnittstelle mit 429 und die Seite zeigt eine allgemeine Fehlermeldung.

Fehlerbehebung

Problem:

Die Seite zeigt „Failed to check headers. Please verify the URL is accessible.“, obwohl sich die Website im Browser normal öffnet.

Lösung:

Diese allgemeine Meldung erscheint, wenn die Antwort unbrauchbar zurückkam. Häufigste Ursache ist das Limit: Ab mehr als zwanzig Prüfungen pro Minute von derselben Adresse antwortet die Schnittstelle mit 429 Too Many Requests. Warten Sie eine Minute und versuchen Sie es erneut. Dieselbe Meldung erscheint, wenn der Server länger als die zehn Sekunden Zeitlimit für eine Antwort auf die HEAD-Anfrage braucht.

Problem:

In der Fehlerzeile steht „Connection failed: SSL certificate problem: certificate has expired“.

Lösung:

Das Zertifikat wird geprüft und nicht blind akzeptiert. Ein abgelaufenes, selbst signiertes oder auf einen anderen Hostnamen ausgestelltes Zertifikat bricht die Prüfung deshalb ab, statt einen irreführenden Bericht zu erzeugen. Erneuern oder korrigieren Sie das Zertifikat, oder prüfen Sie die http://-Adresse, um die Header zu lesen, die der Server vor dem TLS-Aufbau sendet.

Problem:

In der Fehlerzeile steht „Internal URLs not allowed“, „Private IPs not allowed“ oder „This port is not allowed“.

Lösung:

Das Werkzeug lehnt localhost, private und reservierte IP-Bereiche, Cloud-Metadaten-Endpunkte und die Ports 22, 23, 25, 3306, 5432, 6379, 11211, 27017, 8080 und 8443 ab, damit es nicht zum Scanner für interne Netze wird. Nutzen Sie einen öffentlich auflösbaren Hostnamen auf Port 80 oder 443; für einen lokalen Server führen Sie curl -I direkt auf dem Rechner aus.

Problem:

Die Karte Statuscode zeigt 301 oder 302, nur eine Handvoll Header und eine schlechte Sicherheitsbewertung.

Lösung:

Weiterleitungen werden bewusst nicht verfolgt: Bewertet wird die Weiterleitungsantwort, nicht das Ziel. google.com antwortet mit 301 und location: https://www.google.com/ und kommt deshalb auf 25/100. Kopieren Sie den location-Wert aus der Header-Tabelle und starten Sie damit eine zweite Prüfung, um die Seite zu bewerten, auf der Besucher tatsächlich landen.

Problem:

In der Fehlerzeile steht „Connection failed: Could not resolve host“.

Lösung:

Unser Server hat für diesen Hostnamen keinen öffentlichen DNS-Eintrag gefunden. Prüfen Sie die Schreibweise, entfernen Sie ein versehentlich mitkopiertes Leerzeichen oder Anführungszeichen und stellen Sie sicher, dass die Domain auch außerhalb Ihres Netzes auflöst. Ein Host, den es nur in Ihrer hosts-Datei, hinter einem VPN oder auf einem internen Resolver gibt, ist von hier aus nicht erreichbar.

Häufig gestellte Fragen

Geben Sie die Domain in das Feld oben auf dieser Seite ein und drücken Sie die Eingabetaste oder klicken Sie auf Prüfen. Unser Server schickt eine HEAD-Anfrage an diese URL, und die Seite füllt drei Karten – Statuscode, Sicherheitsbewertung, Antwortzeit –, gefolgt von der Auswertung Sicherheits-Header und einer Tabelle aller zurückgegebenen Header. github.com antwortet mit 200 OK in rund 60 ms und 17 Feldern. Erweiterung, curl-Befehl oder Entwicklertools sind dafür nicht nötig.

Ein HTTP-Header ist eine Zeile aus Name und Wert, die eine Anfrage oder eine Antwort beschreibt. content-type: text/html; charset=utf-8 nennt den Medientyp, cache-control legt fest, wie lange die Antwort wiederverwendet werden darf, location nennt das Ziel einer Weiterleitung. RFC 9110, HTTP Semantics, definiert die Syntax der Felder und das Register ihrer Namen. Header laufen neben dem Rumpf, nie darin; diese Seite listet ausschließlich Antwort-Header.

Bewertet werden hier sieben: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy und Permissions-Policy. HSTS und CSP wiegen je 20 Punkte, X-Content-Type-Options und X-Frame-Options je 15, die übrigen drei je 10. MDN führt X-XSS-Protection als veraltet und nicht standardisiert und empfiehlt stattdessen eine belastbare Content-Security-Policy – sehen Sie diese zehn Punkte also als Altlast, nicht als Ziel.

Starten Sie die Prüfung und lesen Sie den Abschnitt Sicherheits-Header: Jeder der sieben trägt eine Markierung Present oder Missing, eine einzeilige Beschreibung und, falls vorhanden, den genauen vom Server gelieferten Wert. Die Karte Sicherheitsbewertung übersetzt das in 0 bis 100 mit einer Note – ab 90 A+, ab 80 A, ab 70 B, ab 60 C, ab 40 D, darunter F. github.com kommt auf 90/100, es fehlt nur Permissions-Policy.

Öffnen Sie mit F12 die Entwicklertools, wechseln Sie zum Reiter Netzwerk, laden Sie die Seite neu, klicken Sie die Dokumentanfrage an und lesen Sie den Bereich mit den Antwort-Headern. Das zeigt, was Ihr eigener Browser empfangen hat, samt Cookies und Inhaltsaushandlung. Diese Seite ist das neutrale Gegenstück: Die Anfrage verlässt unseren Server mit der Kennung FreeWebTools Header Checker/1.0 und ohne Cookies, Sie sehen also, was ein anonymer Besucher bekommt.

Header tragen alles, was an einer Nachricht nicht der Rumpf ist: das Ergebnis der Übertragung, Medientyp und Kodierung, Regeln für Zwischenspeicher und Revalidierung, Cookies und die Sicherheitsrichtlinien, die ein Browser durchsetzen muss. Ohne content-type muss ein Browser das Format raten; ohne strict-transport-security spricht er womöglich weiter einfaches HTTP; ohne content-security-policy läuft ein eingeschleustes Skript ungehindert. Der Rumpf allein kann nichts davon ausdrücken.

Jedes Feld steht in einer Zeile: Name, Doppelpunkt, optionales Leerzeichen und Wert, etwa x-frame-options: deny. RFC 9110, Abschnitt 5.1, macht Feldnamen unabhängig von der Groß- und Kleinschreibung, und HTTP/2 verlangt sie in Kleinbuchstaben – darum steht in der Tabelle oben content-type und nicht Content-Type. Ein Feld darf sich zulässig wiederholen; dieser Prüfer behält dann den zuletzt gelesenen Wert.

Ja. TLS verschlüsselt die gesamte HTTP-Nachricht einschließlich der Header. Wer den Datenverkehr mitliest, sieht die Ziel-IP-Adresse und den SNI-Hostnamen, aber weder Feldnamen noch Werte noch Cookies. Über einfaches HTTP ist nichts geschützt – genau dafür gibt es Strict-Transport-Security: RFC 6797 schreibt dem Browser vor, für diesen Host während der gesamten max-age-Dauer HTTPS zu verwenden, und Browser ignorieren den Header, wenn er über HTTP ankommt.

Bei den Feldnamen nicht. RFC 9110, Abschnitt 5.1, hält fest, dass Feldnamen unabhängig von der Schreibweise sind: Content-Type und content-type bezeichnen dasselbe Feld, und HTTP/2 schreibt die Kleinschreibung vor. Bei den Werten sieht es anders aus – ein Browser akzeptiert x-frame-options: DENY ebenso wie deny, doch eine location-URL, ein ETag oder ein Nonce in einer Content-Security-Policy wird genau so verglichen, wie er geschrieben steht.

Nein. Diese Seite meldet Antwort-Header, denn die Anfrage stellt unser Server und nicht Ihr Browser. Die Header, die Ihr Browser sendet, finden Sie in den Entwicklertools im Reiter Netzwerk unter den Anfrage-Headern oder über einen Dienst, der die Anfrage zurückspiegelt. Alles hier – Status, Bewertung und Tabelle – beschreibt die eingegebene Website, nicht Ihren Client.

FreeWebTools AI
Powered by free AI models · Full chat →