Vérificateur d'En-têtes HTTP
Un vérificateur d'en-têtes HTTP interroge une URL et affiche les en-têtes de réponse renvoyés par le serveur : le code de statut, les champs de cache et de cookies, et les en-têtes de sécurité que le navigateur applique. Celui-ci y ajoute un score sur 100 calculé à partir de sept d'entre eux : HSTS, CSP, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy et Permissions-Policy. Pour github.com, il renvoie 200 OK en 60 ms environ, 17 en-têtes et 90/100, note A+.
En-têtes de Sécurité
Tous les En-têtes de Réponse
| Header | Value |
|---|---|
Que renvoie ce vérificateur d'en-têtes HTTP ?
Saisissez un domaine : l'outil envoie depuis notre serveur une requête HEAD vers cette adresse, puis affiche le code de statut, le temps d'aller-retour en millisecondes, la liste complète des en-têtes de réponse et un score de sécurité sur 100 fondé sur HSTS, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy et Permissions-Policy. Il rapporte ce que le serveur a envoyé : il ne suit pas les redirections et ne lit pas le corps de la page.
Outils populaires
À propos de Vérificateur d'En-têtes HTTP
Ce vérificateur d'en-têtes HTTP prend une URL, envoie vers elle une requête HEAD depuis notre serveur et affiche ce qui revient : le code de statut avec sa phrase de statut, le temps d'aller-retour en millisecondes et chaque en-tête de réponse envoyé par le serveur. Pour github.com, il renvoie 200 OK en 60 ms environ et 17 champs d'en-tête, de content-type et etag à la valeur complète de content-security-policy.
La carte Score de Sécurité note sept en-têtes sur 100. Strict-Transport-Security et Content-Security-Policy valent 20 points chacun, X-Content-Type-Options et X-Frame-Options 15 chacun, et X-XSS-Protection, Referrer-Policy et Permissions-Policy 10 chacun. À partir de 90 points la note est A+, 80 donne A, 70 B, 60 C, 40 D et en dessous F. github.com obtient 90/100 parce que Permissions-Policy est absent ; example.com n'envoie aucun des sept et obtient 0.
Le score compte la présence, pas la qualité. La valeur x-xss-protection: 0 désactive ce filtre et rapporte quand même ses dix points, tandis qu'un en-tête content-security-policy-report-only n'en rapporte aucun : lisez donc les valeurs affichées sous chaque ligne marquée Present plutôt que la seule note. Les redirections ne sont pas suivies : google.com répond 301 avec location: https://www.google.com/, et il faut coller cette adresse pour noter la destination. La requête est de type HEAD, donc aucun code HTML, aucune balise meta et aucun texte de page n'est analysé ; elle abandonne au bout de dix secondes, et vingt vérifications par minute sont acceptées depuis une même adresse.
L'URL que vous saisissez est envoyée au serveur de ce site, qui effectue la requête à votre place avec l'agent utilisateur FreeWebTools Header Checker/1.0 et sans aucun de vos cookies ni votre session : vous voyez donc ce que reçoit un visiteur anonyme. Les plages d'adresses IP privées et réservées, localhost, les points d'accès aux métadonnées cloud et les ports d'administration comme 22, 3306 et 6379 sont refusés.
Cas d'utilisation
Comment vérifier les en-têtes de réponse HTTP d'un site
Saisissez un domaine ou une adresse complète dans le champ de recherche, par exemple example.com ; le préfixe https:// est ajouté pour vous. Vous pouvez aussi cliquer sur un des exemples à côté de Essayer : google.com, github.com, cloudflare.com ou stackoverflow.com.
Appuyez sur Entrée ou cliquez sur Vérifier. La requête part de notre serveur sous forme de requête HEAD : seuls les en-têtes reviennent, jamais le corps de la page.
Lisez les trois cartes de synthèse : Code d'État avec sa phrase de statut, Score de Sécurité sur 100 avec sa note en lettre, et Temps de Réponse en millisecondes.
Parcourez En-têtes de Sécurité pour voir lesquels, parmi HSTS, CSP, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy et Permissions-Policy, sont marqués Present ou Missing, et lisez la valeur affichée sous chacun de ceux qui sont présents.
Ouvrez Tous les En-têtes de Réponse pour lire le nom et la valeur de chaque en-tête renvoyé par le serveur, y compris les champs de cache, de cookie et de CDN que le score ne couvre pas.
Cliquez sur Copier pour placer tout le rapport — URL, statut, score avec la note et la liste des en-têtes — dans votre presse-papiers en texte brut.
Astuces Pro
- Saisissez le domaine seul : le champ ajoute https:// pour vous, donc github.com est vérifié comme https://github.com. Écrivez http:// explicitement pour voir la réponse en HTTP simple, où strict-transport-security est normalement absent, la RFC 6797 demandant aux navigateurs de l'ignorer sur une connexion non sécurisée.
- Le score récompense la présence, pas la valeur. github.com envoie x-xss-protection: 0, ce qui désactive le filtre, et empoche malgré tout les dix points : lisez la ligne de valeur grise sous chaque ligne marquée Present avant de vous fier à la note.
- Une politique en mode report-only ne rapporte rien. google.com envoie content-security-policy-report-only sans politique appliquée et perd donc les 20 points de CSP ; l'étiquette Present n'apparaît que pour le nom d'en-tête exact content-security-policy.
- Quand la carte Code d'État affiche 301 ou 302, copiez la valeur location depuis le tableau des en-têtes et lancez une deuxième vérification dessus. La réponse de redirection ne porte presque aucun en-tête de sécurité, ce qui explique le 25/100 de google.com.
- Le bouton Copier place tout le rapport dans le presse-papiers en texte brut — URL, statut, score avec la note et chaque en-tête — c'est ce que vous collez dans un ticket. Réglez le travail en série sur vingt vérifications par minute ; au-delà, l'API répond 429 et la page affiche un message d'échec générique.
Dépannage
La page affiche « Failed to check headers. Please verify the URL is accessible. » alors que le site s'ouvre normalement dans votre navigateur.
Ce message générique apparaît quand la réponse est inexploitable. La cause la plus fréquente est la limite de débit : au-delà de vingt vérifications par minute depuis la même adresse, l'API répond 429 Too Many Requests. Attendez une minute et recommencez. Le même message apparaît quand le serveur met plus de dix secondes, le délai d'expiration, à répondre à une requête HEAD.
La ligne d'erreur indique « Connection failed: SSL certificate problem: certificate has expired ».
Le certificat est vérifié et non accepté aveuglément : un certificat expiré, auto-signé ou émis pour un autre nom d'hôte interrompt donc la vérification au lieu de produire un rapport trompeur. Renouvelez ou corrigez le certificat, ou vérifiez l'adresse en http:// pour lire les en-têtes envoyés avant l'intervention de TLS.
La ligne d'erreur indique « Internal URLs not allowed », « Private IPs not allowed » ou « This port is not allowed ».
L'outil refuse localhost, les plages d'adresses IP privées et réservées, les points d'accès aux métadonnées cloud et les ports 22, 23, 25, 3306, 5432, 6379, 11211, 27017, 8080 et 8443, afin de ne pas devenir un scanner de réseau interne. Utilisez un nom d'hôte résolvable publiquement sur le port 80 ou 443 ; pour un serveur local, lancez curl -I depuis la machine elle-même.
La carte Code d'État affiche 301 ou 302 avec une poignée d'en-têtes seulement et un score de sécurité médiocre.
Les redirections ne sont volontairement pas suivies : ce que vous notez est la réponse de redirection, pas la destination. google.com répond 301 avec location: https://www.google.com/ et obtient 25/100 pour cette raison. Copiez la valeur location depuis le tableau des en-têtes et relancez une vérification dessus pour noter la page où les visiteurs arrivent réellement.
La ligne d'erreur indique « Connection failed: Could not resolve host ».
Notre serveur n'a trouvé aucun enregistrement DNS public pour ce nom d'hôte. Vérifiez l'orthographe, supprimez l'espace ou le guillemet collé par mégarde avec l'adresse, et confirmez que le domaine se résout depuis l'extérieur de votre réseau. Un hôte qui n'existe que dans votre fichier hosts, derrière un VPN ou sur un résolveur interne ne peut pas être atteint d'ici.
Questions fréquemment posées
Saisissez le domaine dans le champ en haut de cette page et appuyez sur Entrée ou cliquez sur Vérifier. Notre serveur envoie une requête HEAD vers cette URL et la page remplit trois cartes — Code d'État, Score de Sécurité, Temps de Réponse — suivies de l'analyse En-têtes de Sécurité et d'un tableau de tous les en-têtes reçus. github.com répond 200 OK en 60 ms environ avec 17 champs. Aucune extension, aucune commande curl ni aucun outil de développement n'est nécessaire.
Un en-tête HTTP est une ligne nom-valeur attachée à une requête ou à une réponse pour la décrire. content-type: text/html; charset=utf-8 indique le type de média, cache-control indique combien de temps la réponse peut être réutilisée, location nomme la cible d'une redirection. La RFC 9110, HTTP Semantics, définit la syntaxe des champs et le registre de leurs noms. Les en-têtes voyagent à côté du corps, jamais dedans ; cette page ne liste que les en-têtes de réponse.
Les sept notés ici sont Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy et Permissions-Policy. HSTS et CSP pèsent 20 points chacun, X-Content-Type-Options et X-Frame-Options 15 chacun, les trois autres 10 chacun. MDN qualifie X-XSS-Protection de dépréciée et non standard et recommande à la place une Content-Security-Policy solide : voyez ces dix points comme un signal hérité, pas comme un objectif.
Lancez la vérification et lisez la section En-têtes de Sécurité : chacun des sept en-têtes porte une étiquette Present ou Missing, une description d'une ligne et, s'il est présent, la valeur exacte renvoyée par le serveur. La carte Score de Sécurité traduit cela en 0-100 avec une note — 90 et plus donnent A+, 80 A, 70 B, 60 C, 40 D, en dessous de 40 F. github.com obtient 90/100, seul Permissions-Policy lui manquant.
Appuyez sur F12 pour ouvrir les outils de développement, passez à l'onglet Réseau, rechargez la page, cliquez sur la requête du document et lisez le panneau des en-têtes de réponse. Vous voyez alors ce que votre propre navigateur a reçu, cookies et négociation de contenu compris. Cette page en est la contrepartie neutre : la requête part de notre serveur avec l'agent utilisateur FreeWebTools Header Checker/1.0 et sans cookie, donc vous voyez ce que reçoit un visiteur anonyme.
Les en-têtes portent tout ce qui, dans un message, n'est pas le corps : l'issue du transfert, le type de média et l'encodage, les règles de cache et de revalidation, les cookies et les politiques de sécurité que le navigateur doit appliquer. Sans content-type, un navigateur doit deviner le format ; sans strict-transport-security, il peut continuer en HTTP simple ; sans content-security-policy, un script injecté s'exécute sans obstacle. Le corps seul ne peut rien exprimer de tout cela.
Chaque champ tient sur une ligne : un nom, deux-points, un espace facultatif et une valeur, comme x-frame-options: deny. La RFC 9110, section 5.1, rend les noms de champs insensibles à la casse, et HTTP/2 les impose en minuscules — d'où content-type plutôt que Content-Type dans le tableau ci-dessus. Un champ peut légitimement se répéter ; ce vérificateur conserve alors la dernière valeur analysée.
Oui. TLS chiffre l'ensemble du message HTTP, en-têtes compris : un observateur du réseau voit l'adresse IP de destination et le nom d'hôte SNI, mais ni les noms de champs, ni les valeurs, ni les cookies. En HTTP simple, rien n'est protégé, et c'est précisément le rôle de Strict-Transport-Security : la RFC 6797 impose au navigateur d'utiliser HTTPS pour cet hôte pendant toute la durée de max-age, et les navigateurs ignorent l'en-tête s'il arrive en HTTP.
Les noms de champs, non. La RFC 9110, section 5.1, précise que les noms de champs sont insensibles à la casse : Content-Type et content-type désignent le même champ, et HTTP/2 impose la forme en minuscules. Les valeurs, c'est autre chose : un navigateur accepte aussi bien x-frame-options: DENY que deny, mais une URL location, un ETag ou un nonce dans une Content-Security-Policy sont comparés exactement tels qu'écrits.
Non. Cette page rapporte des en-têtes de réponse, car la requête est émise par notre serveur et non par votre navigateur. Pour lire les en-têtes que votre navigateur envoie, ouvrez les outils de développement, allez dans l'onglet Réseau et dépliez les en-têtes de requête, ou utilisez un service d'écho de requête. Tout ce qui est affiché ici — le statut, le score et le tableau — décrit le site que vous avez saisi, pas votre client.