PeopleAreGeek
EN

HTTP Headers Checker

Récupère les HTTP response headers en direct de n'importe quelle URL et lis-les comme un rapport : couverture sécurité, cache, redirections et flags des cookies.

Ce HTTP headers checker récupère les response headers en direct de n'importe quelle URL depuis notre serveur, puis te les rend sous forme de rapport que tu peux coller direct dans un ticket au lieu de faire un curl et de plisser les yeux. Tu obtiens le statut, le temps de réponse, les indices de redirection, et les headers qui comptent vraiment : les security policies remises au navigateur, l'histoire du cache et de la compression, le content type, les flags des cookies, et le volume sonore avec lequel ton stack annonce son build. Il note la couverture des security headers face à une base sensée de cinq, flague une ligne Server ou X-Powered-By bavarde, et indique ce qu'il faut corriger aujourd'hui versus ce qu'il faut tester en staging d'abord. Il lit l'URL exacte que tu tapes et ne suit pas les redirections, donc un 301 apparaît comme un 301, et l'onglet redirect retrace le chemin tout seul. Les valeurs brutes restent à l'écran tout le temps.

Les requêtes passent par le service de lookup PeopleAreGeek. Nous ne journalisons rien.

Audit des HTTP response en direct

J'en avais marre de faire un curl sur un site et de plisser les yeux sur les headers, à compter mentalement ce qui manque. Du coup j'ai bricolé ça. L'outil récupère les headers de réponse depuis notre serveur, puis te sort un rapport que tu peux coller direct dans un ticket. Le statut. Le temps de réponse. Les indices de redirection, les security headers, le cache et la compression, le content type, les flags des cookies, et le volume sonore avec lequel ton stack s'annonce. Et les valeurs brutes ne sont jamais cachées. Elles sont juste là.

Un truc à savoir. L'outil envoie un HEAD côté serveur vers l'URL exacte que tu lui donnes, et il ne suivra pas les redirections à ta place. L'URL rebondit ailleurs ? L'onglet redirect demande discrètement au redirect checker de retracer le chemin tout seul.

Ce qu'un HTTP headers checker devrait te dire

Un HTTP headers checker récupère le petit mot que le serveur griffonne au navigateur, les lignes gribouillées avant que le moindre pixel ne s'affiche. Le statut est-il sain ? Y a-t-il une redirection en jeu, la compression a-t-elle bien démarré, quel content type est vraiment revenu, et quelles security policies ont été remises au navigateur. J'ai audité des pages impeccables à l'écran qui avaient quand même une policy grande ouverte en dessous, un caching qui ne se rafraîchissait jamais, un server header qui diffusait joyeusement sa version exacte. Donc oui. Que la page soit nickel et que les headers soient nickel, ce sont deux choses très différentes.

Conçu pour le vrai boulot, pas pour une jolie capture d'écran. Les valeurs brutes restent à l'écran. Mais l'outil les transforme aussi en décisions concrètes : ce qui est là, ce qui ne l'est pas, ce qu'il faut corriger aujourd'hui, et ce que tu ferais honnêtement mieux de tester en staging d'abord avant d'aller bidouiller un WordPress live derrière un CDN.

Les headers à lire en premier

  • Status et Location ont droit à mon premier coup d'oeil. Est-ce que j'ai récupéré une page, ou est-ce que je me suis fait renvoyer ailleurs ?
  • Content-Type me dit ce qui est vraiment revenu. Du HTML, du JSON, une image, un téléchargement, ou un truc auquel je ne m'attendais franchement pas.
  • Cache-Control, ETag, Last-Modified et Vary, c'est toute l'histoire du caching, du début à la fin.
  • Content-Encoding me dit une seule chose : est-ce que cette réponse précise est partie compressée.
  • Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy et les frame headers, ce sont ceux qui verrouillent vraiment le navigateur.

Les security headers ont besoin de contexte

Un header manquant, ce n'est pas un bouton que tu actives à la volée. Prends HSTS. Active-le avant que le HTTPS soit béton sur tout le host et chaque sous-domaine que tu sers, et tu peux te bannir proprement de ton propre site. CSP, c'est celui qui m'a mordu le plus fort, honnêtement. Balance une policy stricte dans la précipitation et tu finiras par expliquer à quelqu'un pourquoi le formulaire de contact, les analytics, les emplacements pub, un embed, la moitié de wp-admin se sont tous discrètement arrêtés. Le contrôle du framing peut vivre dans CSP frame-ancestors, dans X-Frame-Options, ou les deux, si tu tiens encore aux vieux clients. Donc lis le rapport. Teste-le en staging si tu en as un. Et toujours, toujours, reteste à travers ton CDN une fois que c'est en prod.

Headers, performance et SEO

Petit mythe à enterrer une bonne fois : Google ne te classera pas plus haut parce que ton tableau de headers a l'air bien rangé. Ce qu'il remarque, en revanche, c'est si les pages répondent de façon fiable, redirigent de la même manière à chaque fois, restent en HTTPS, renvoient le contenu prévu sans coller de friction aux utilisateurs ni aux crawlers. Des headers propres, c'est le plancher sous tout ça. Ils gagnent leur place aux côtés d'un vrai contenu, de liens internes sensés, d'un sitemap qui couvre réellement les choses, de pages vraiment indexables. À côté, attention. Pas à la place.

Questions fréquentes

Pourquoi le checker affiche-t-il une redirection au lieu des headers de la page finale ?

Parce qu'il lit l'URL exacte que tu as tapée. Point final. Il ne suit pas le rebond. Donc si cette URL est un 301 ou un 302, c'est la redirection qui revient, et c'est la bonne réponse. Retrace le chemin dans l'onglet redirect. Puis passe aussi la destination finale ici, parce que c'est là que se trouvent les headers qui t'intéressent vraiment.

Un server header est-il toujours une vulnérabilité ?

Non. Je ne perdrais pas une minute de sommeil pour un header tout simple. La moitié du web annonce un nom de serveur générique et il n'en sort jamais rien de mauvais. Ce que je rogne, c'est la version bavarde. À la seconde où un header détaille ton build exact, tu as en gros tendu à un attaquant la liste des CVE à essayer en premier. Pourquoi lui faciliter cette partie.

Une compression absente ici veut-elle dire que tout le site n'est pas compressé ?

Pas forcément. La compression varie selon le type de fichier, selon quel noeud du CDN a répondu, selon la méthode de requête, même selon la taille brute de la réponse. Les tout petits payloads la sautent volontairement la moitié du temps. Donc lis ça comme un point de donnée. Pas comme le verdict. Puis reteste le chemin exact qui t'inquiète vraiment.

Quels security headers chaque site devrait-il envoyer ?

Ma base monte à cinq. Strict-Transport-Security, une Content-Security-Policy, X-Content-Type-Options réglé sur nosniff, une Referrer-Policy, et le framing verrouillé avec X-Frame-Options ou CSP frame-ancestors. Cloue ça et les gains faciles sont à peu près derrière toi.

À quoi sert le header Cache-Control ?

C'est l'instruction que tu donnes aux navigateurs et aux CDN à propos de cette réponse-là. Peuvent-ils la stocker ? Pendant combien de temps, et quand doivent-ils revenir vérifier qu'elle est toujours fraîche. Rate-le et les gens fixent soit des pages périmées, soit ils martèlent ton origine sans raison valable.

Pourquoi les vérifications de headers côté serveur diffèrent-elles de mon navigateur ?

Parce qu'il se passe beaucoup de choses entre l'origine et tes devtools. Un edge CDN, un reverse proxy, même le cache de ton propre navigateur, n'importe lequel peut ajouter des headers ou en supprimer quelques-uns en douce. Cet outil parle directement au serveur. Donc ce que tu vois, c'est ce que l'origine a vraiment mis sur le fil. Pas ce qui a péniblement survécu au trajet.