Vérificateur d'en-têtes HTTP
Inspectez les en-têtes HTTP et la posture de sécurité de n'importe quelle URL.
🌐 sitekits fetches the URL server-side (private/internal addresses are blocked). Response body is not retrieved.
Vue d’ensemble
Les en-têtes de réponse sont l’endroit où l’essentiel du comportement d’un site est réellement configuré — mise en cache, compression, politique de sécurité, CORS, redirections — et c’est la partie que vous ne pouvez pas voir dans le navigateur sans ouvrir les DevTools sur la bonne requête.
Cet outil demande une URL côté serveur et renvoie les en-têtes de réponse, ainsi que la chaîne complète des redirections qui y a mené. Comme le modèle de sécurité du navigateur cache à JavaScript les en-têtes de réponse d’une autre origine, c’est l’un des rares outils d’ici qui ne peut pas s’exécuter entièrement dans votre page.
Utilisation
- Saisissez une URL. Le schéma est optionnel —
example.comest traité commehttps://example.com. - Lisez d’abord la chaîne de redirections. Chaque saut affiche son URL et son code d’état.
- Lisez les en-têtes de la réponse finale.
La chaîne de redirections est souvent la réponse
Quand quelque chose est lent ou qu’une URL canonique est fausse, c’est dans la chaîne que vous le voyez. Chaque saut est un aller-retour complet, et les motifs courants sont tous évitables :
http://example.com→https://example.com→https://www.example.comfait deux redirections là où une seule suffirait. Redirigez directement vers l’hôte et le schéma définitifs, en un seul saut.- Un
301qui atterrit sur un autre301après une migration de site signifie que deux générations de règles sont encore actives en même temps. - Une redirection vers une URL qui redirige en retour est une boucle ; l’outil s’arrête après cinq sauts au lieu de la suivre.
- Un
302là où vous vouliez un301annonce aux robots que le déplacement est temporaire : l’ancienne URL garde donc son classement et la nouvelle n’en accumule aucun.
La distinction entre 301/302 et 307/308 porte sur la méthode de la requête.
Historiquement, les clients transformaient un POST en GET en suivant 301 et
302 ; 307 et 308 préservent la méthode. Si la soumission d’un formulaire se
comporte étrangement derrière une redirection, c’est la première chose à vérifier.
Les en-têtes à lire de près
| En-tête | Ce qu’il faut regarder |
|---|---|
cache-control | no-store sur une ressource statique gâche de la bande passante ; un max-age long sur du HTML rend les déploiements invisibles |
etag / last-modified | Leur absence signifie que chaque revalidation retransfère le corps entier |
content-encoding | L’absence de gzip ou br sur les réponses textuelles est le gain de performance le moins coûteux qui existe |
vary | Vary: User-Agent fragmente chaque cache de CDN en centaines de copies |
strict-transport-security | Un max-age court, ou un includeSubDomains manquant, laisse la première requête déclassable |
content-security-policy | Voir le générateur de CSP pour la signification des directives |
x-content-type-options | Sans nosniff, un content-type erroné peut être réinterprété comme du script |
access-control-allow-origin | La raison de l’échec de votre fetch est presque toujours ici, ou absente |
set-cookie | Vérifiez Secure, HttpOnly et SameSite sur tout ce qui transporte une session |
server et x-powered-by méritent l’attention pour la raison inverse : ils
divulguent des versions de logiciels et rien d’autre. Les retirer n’est pas une
mesure de sécurité, mais aucun argument ne plaide pour les garder.
Ce que l’outil se refuse à faire
Le gestionnaire valide l’URL contre une liste de plages d’adresses privées, de
boucle locale, de lien local et réservées avant de se connecter, et il répète ce
contrôle à chaque saut de redirection. Sans le contrôle par saut, un nom d’hôte
public pourrait rediriger vers 127.0.0.1 ou vers une adresse de métadonnées de
cloud, et la requête suivrait — c’est ainsi qu’un service de vérification
d’en-têtes devient un moyen de sonder le réseau interne d’autrui depuis
l’extérieur.
Il ne transmet jamais non plus le corps de la réponse. La connexion est lue pour ses en-têtes puis abandonnée. Un service qui renvoie des corps arbitraires est un proxy ouvert, que ce fût l’intention ou non.
Les identifiants intégrés dans une URL (https://user:pass@host/) sont retirés
avant l’émission de la requête : ils ne sont donc ni envoyés à la cible, ni
renvoyés en écho dans la chaîne de redirections.
Exemples
- Une erreur CORS que vous n’arrivez pas à reproduire. Comparez
access-control-allow-originsur le vrai point d’entrée à ce que votre code attend. Un en-tête absent et un en-tête faux produisent le même message dans le navigateur. - Un déploiement qui refuse d’apparaître. Regardez
cache-controletagesur le HTML. Un CDN qui sert un document en cache l’explique plus souvent que la compilation. - Auditer le déploiement d’en-têtes de sécurité. Vérifiez
strict-transport-security,content-security-policyetx-content-type-optionssur l’hôte en production plutôt que dans votre configuration, parce qu’un CDN ou un WAF peut en ajouter, en retirer ou en écraser n’importe lequel. - Vérifier une redirection canonique. Confirmez que la chaîne se termine en exactement un saut, sur l’hôte et le schéma que vous visez.
Remarques
Les requêtes utilisent un User-Agent fixe qui identifie cet outil, et expirent au
bout de cinq secondes. Un site qui bloque les agents inconnus répondra par un
403, ce qui est une réponse authentique sur la configuration de ce site plutôt
qu’un échec de notre côté.
Les noms d’en-têtes sont affichés tels que le serveur les a envoyés. HTTP/2 impose
des noms en minuscules sur le réseau, donc une réponse en HTTP/2 affichera
content-type là où une réponse en HTTP/1.1 pourrait afficher Content-Type. Les
noms sont insensibles à la casse dans les deux cas.
S’il vous faut envoyer des en-têtes personnalisés, une méthode précise ou un corps de requête, utilisez plutôt le testeur d’API REST — il s’exécute depuis votre propre navigateur et peut donc faire des choses qu’un service partagé ne doit pas faire.