Vérificateur d'en-têtes HTTP
Affichez les en-têtes de réponse HTTP et la chaîne de redirections de n'importe quelle URL, avec un audit des en-têtes de sécurité.
Chargement de Vérificateur d'en-têtes HTTP… Si rien ne se passe, activez JavaScript.
Chaque réponse web commence par un bloc d'en-têtes HTTP que le visiteur ne voit jamais : le code de statut, la cible d'une redirection, la durée pendant laquelle la page peut rester en cache, le type de contenu et une série d'instructions de sécurité pour le navigateur. La plupart des problèmes de SEO, de performance et de sécurité y laissent leur première trace : une boucle de redirections, un 302 qui devrait être un 301, un en-tête HSTS absent, un CDN qui refuse de mettre en cache. Cet outil demande une URL depuis notre serveur et affiche ces en-têtes tels qu'ils arrivent.
Exemples
http://github.com
301 → https://github.com/ → 200
Une redirection de HTTP vers HTTPS, puis la page finale avec HSTS, CSP et X-Frame-Options définis.
Cache-Control: max-age=0, private, must-revalidate
Stored, but revalidated with the server on every use (browser only, not CDNs).
Le résumé du cache traduit les directives en langage clair.
Questions fréquentes
Quelle est la différence entre une redirection 301 et une 302 ?
À partir de combien de redirections est-ce trop ?
Quels en-têtes de sécurité comptent le plus ?
Pourquoi les en-têtes diffèrent-ils de ceux des outils de développement de mon navigateur ?
Pourquoi l'outil indique-t-il GET au lieu de HEAD ?
Puis-je vérifier une page sur localhost ou sur mon réseau interne ?
L'outil vérifie-t-il le certificat TLS ?
Les URL que je vérifie sont-elles conservées ?
À propos de Vérificateur d'en-têtes HTTP
Collez une URL et le vérificateur la demande comme le ferait un navigateur, sans suivre automatiquement les redirections. Chaque saut apparaît dans l'ordre avec son code de statut, son temps de réponse et la liste complète de ses en-têtes : vous voyez tout le trajet de http://example.com jusqu'au https://www.example.com/ final et repérez les sauts superflus qui ralentissent la première visite. Cliquez sur un saut pour afficher ses en-têtes, filtrez-les par nom ou par valeur et copiez-les en texte brut.
La réponse finale fait l'objet d'un audit des en-têtes de sécurité. L'outil vérifie Strict-Transport-Security (et son max-age), Content-Security-Policy (et si elle autorise encore les scripts unsafe-inline), X-Frame-Options ou frame-ancestors de la CSP contre le clickjacking, X-Content-Type-Options, Referrer-Policy, Permissions-Policy et Cross-Origin-Opener-Policy, et signale les en-têtes qui révèlent les versions logicielles du serveur. Chaque point explique simplement le rôle de l'en-tête et ce qui manque. Une section distincte traduit Cache-Control, Expires, ETag, Age et Vary en une réponse d'une ligne sur la mise en cache de la page.
Les requêtes partent de notre serveur : vous voyez donc la réponse publique, pas ce qu'envoie votre navigateur ou un proxy local. Une requête HEAD est tentée d'abord, puis un GET si le serveur refuse HEAD, interrompu dès l'arrivée des en-têtes pour ne télécharger aucun corps de page. Seuls http et https sur les ports 80, 443, 8080 et 8443 sont autorisés, chaque cible de redirection est revérifiée et les adresses privées ou internes sont bloquées.
Des en-têtes qui ont survécu à leur raison d'être
Les en-têtes HTTP accumulent de l'histoire. L'en-tête Referer est mal orthographié parce que Phillip Hallam-Baker l'a écrit avec un seul « r » dans le brouillon des années 90, et quand quelqu'un s'en est aperçu, des serveurs du monde entier en dépendaient déjà. Le plus récent Referrer-Policy est correctement orthographié, si bien que le web transporte désormais les deux graphies côte à côte.
X-XSS-Protection est un en-tête qui a fini par être désactivé volontairement. Internet Explorer 8 a introduit un filtre XSS en 2008 et Chrome a suivi, mais des chercheurs ont montré que le filtre lui-même pouvait être détourné pour divulguer des données ou désactiver des scripts légitimes. Chrome a supprimé son XSS Auditor en 2019, et la valeur recommandée aujourd'hui est 0, ou pas d'en-tête du tout, le vrai travail revenant à Content-Security-Policy.
Le préfixe X- lui-même a été officiellement déconseillé par la RFC 6648 en 2012. L'idée était que les en-têtes expérimentaux portent X- puis le perdent une fois normalisés, mais des en-têtes populaires comme X-Forwarded-For et X-Frame-Options ne l'ont jamais perdu, car les renommer n'aurait fait que tout casser. Les nouveaux en-têtes sont désormais enregistrés sans préfixe dès le départ.