Vérificateur d'en-têtes HTTP

Lancez le Vérificateur d'en-têtes HTTP après déploiement d'un nouvel origine, changement de mode orange-cloud CDN ou activation HSTS. Cache-Control et en-têtes CDN expliquent un HTML obsolète malgré un deploy récent — comparez ETag et max-age avant purge aveugle. Si Server diffère de l'attendu, confirmez A/AAAA via Vérificateur DNS — vous touchez peut-être une vieille IP de load balancer.

Les revues sécurité utilisent HSTS, CSP, X-Frame-Options, Referrer-Policy et Permissions-Policy pour la baseline. Sans HSTS sur sites HTTPS-only, fenêtre de downgrade à la première visite. CSP mal configurée casse les scripts en prod — le vérificateur capture la politique live pour diff staging. Le Vérificateur de certificat SSL valide le certificat ; les en-têtes valident ce que l'app envoie après terminaison TLS.

Le debug redirect profite de la chaîne complète : liens courts marketing, règles apex→www et upgrades http→https ajoutent des sauts. Le support a souvent besoin de la cible Location exacte du 301 — copiez depuis l'outil plutôt que deviner depuis la barre d'adresse.

Les équipes API et SPA inspectent CORS (Access-Control-Allow-Origin) quand la console bloque des fetches. Les en-têtes prouvent ce que l'edge renvoie aux GET non authentifiés — distinct du preflight POST à tester séparément.

Conformité et bandeaux cookies cataloguent Set-Cookie : Secure, HttpOnly, SameSite. Le vérificateur documente l'émission sur l'URL analysée — utile avant audits privacy. DN01 ne scanne pas tout le site sur chaque chemin ; commencez par l'URL investiguée.

Les load balancers retirent parfois Server et ajoutent Via — documentez les deux pour durcir l'empreinte. Les pentesters exploitent la variance d'en-têtes pour cartographier CDN vs origine ; votre ticket hardening doit lister les différences intentionnelles par hostname.

Les apps mobiles sans DevTools — collez les URLs API en échec dans le vérificateur pour capturer les en-têtes 401/403 (WWW-Authenticate, Retry-After) sans repro sur appareil.

Les équipes plateforme comparent en-têtes avant/après activation Brotli CDN — Content-Encoding et Vary doivent s'aligner sur la politique cache du runbook performance.

Lors d'audits SOC2 ou ISO, exportez la sortie du Vérificateur d'en-têtes HTTP avec captures Vérificateur DNS et Vérificateur de certificat SSL — contrôles edge sans fausse couverture mondiale.

Lors d'une bascule blue/green, comparez en-têtes sur l'ancien et le nouveau pool avant de basculer le trafic — HSTS et cookies de session doivent rester cohérents pour éviter des boucles de login après cutover.

Des en-têtes différents sur la même URL via VPN bureau vs mobile indiquent souvent CDN géo-routé ou enregistrements A partagés — comparez Vérificateur DNS et refetch. Nous montrons un instantané, pas cinquante edge nodes mondiaux.

301 vs 302 vs 307 comptent pour SEO et préservation de méthode. Le vérificateur expose les codes par saut — toutes les redirections ne sont pas équivalentes. Meta refresh HTML est hors scope HTTP ; voyez la source si Location manque mais le navigateur bouge.

Cache-Control obsolète avec long max-age au CDN alors que l'origine envoie no-cache signifie override edge — corrigez la règle CDN, purgez, revérifiez. Cache-Control vide sur assets statiques peut sur-revalider — voulu sur HTML, coûteux sur assets immuables.

En-têtes sécurité sur www mais absents sur apex (ou inverse) signifient souvent vhost incomplet. Testez les deux hostnames. HSTS sur une seule étiquette laisse les sœurs vulnérables — alignez vhosts TLS et relancez Vérificateur de certificat SSL pour couverture SAN.

Content-Encoding brotli ou gzip affecte le corps, pas la sémantique des en-têtes — ne confondez pas Content-Length manquant sur chunked avec erreur ; focus cache et sécurité pour audits politique.

Les en-têtes HTTP sont au-dessus de TCP/TLS. Un certificat valide du Vérificateur de certificat SSL n'implique pas cache ou CSP corrects. Inversement, en-têtes parfaits sur mauvaise IP signifient DNS ailleurs pour certains resolvers — triangulez Vérificateur DNS et DIG sur A/AAAA.

Les proxies CDN terminent TLS et peuvent retirer ou injecter des en-têtes. Server et Via révèlent le nombre de proxies. Diagnostic origine seule requiert grey-cloud ou fetch direct — DN01 fetch l'URL publique saisie, typiquement via le chemin DNS d'aujourd'hui.

Listes preload HSTS et certificate transparency hors scope. Le vérificateur montre Strict-Transport-Security live — suffisant pour beaucoup d'audits, pas substitut au registre preload ni monitoring CT.

Automatisez les régressions d'en-têtes via l'API documentée après enregistrement token. L'UI navigateur reste idéale pour enquêtes ad hoc avec copie — pas de SIEM ni dashboard WAF.

HTTP/3 et QUIC changent l'établissement mais beaucoup d'en-têtes sécurité restent sémantiques HTTP — le vérificateur documente sur le chemin négocié aujourd'hui.

304 Not Modified dépend du If-None-Match client — le vérificateur sur URL nue peut montrer 200 alors que navigateurs avec ETag voient 304 ; documentez les conditions.

DN01 n'exécute pas JavaScript — les SPA qui posent des en-têtes sécurité après render client peuvent tromper si seules URLs d'hébergement statique sont inspectées.

X-Content-Type-Options: nosniff et Cross-Origin-Opener-Policy complètent CSP — le vérificateur liste déclarations serveur sur une GET reproductible en tickets.

Quand un WAF renvoie des pages défi bot, les en-têtes peuvent montrer Set-Cookie de mitigation distincts de l'app — documentez le hostname exact attaqué avant comparaison staging.

curl -I est la norme opérateur mais bloqué sur beaucoup de laptops corporate et intimidant pour non-CLI. DN01 formate pour copie avec chaînes redirect visibles — même classe d'info, UX plus douce, huit langues.

DevTools Network excelle en debug interactif POST et WebSockets. Le vérificateur vise snapshots GET/HEAD de métadonnées réponse pour tickets — pas export HAR complet.

Scanners sécurité dédiés crawlen, notent en-têtes et suivent CVE. DN01 fournit fetch honnête URL unique sans badge payant — combinez pour profondeur, DN01 pour « que renvoie cette URL maintenant ? »

Pas de redirects JavaScript arbitraires, pas d'auth app, pas de base historique par client. Rate limits protègent le service. Cartes propagation globales hors scope — Vérificateur DNS et DIG pour adressage ; nous métadonnées HTTP.

Équipes WAF enterprise maintiennent allowlists — coordonnez avant automatisation haut volume production.

Tag managers injectent scripts — le vérificateur documente déclarations serveur ; Lighthouse et RUM mesurent l'expérience client.

Gateways proxy auth renvoient 302 login avec Set-Cookie — capturez pour debug SSO ; DN01 documente redirects pre-auth confus pour clients API JSON.

Les APM corrèlent latence et taille réponse — le vérificateur ne mesure pas TTFB ni waterfall mais prouve politique cache déclarée absente des alertes utilisateur.

Extensions navigateur modifiant en-têtes localement ne reflètent pas clients externes — fetch DN01 depuis infra neutre évite faux positifs laptop développeur.

Runbooks disaster recovery doivent relancer le Vérificateur d'en-têtes HTTP après fail-over DNS — confirmez HSTS et redirects avant restauration métier.

Les équipes SRE archivent captures Vérificateur d'en-têtes HTTP dans postmortems — preuve reproductible sans accès shell sur laptops verrouillés des participants incident.