Aller au contenu
IPeek

Vérification des en-têtes HTTP

Inspectez les en-têtes de réponse, redirections et sécurité

Vérification…

Que sont les en-têtes de réponse HTTP ?

Les en-têtes de réponse HTTP révèlent le comportement d'un serveur web : le code de statut qu'il renvoie, vers où il redirige, quel logiciel il exécute et quels en-têtes de durcissement de sécurité il envoie. L'absence d'en-têtes comme HSTS, Content-Security-Policy ou X-Frame-Options expose les sites aux attaques par rétrogradation, par injection et par clickjacking. IPeek suit toute la chaîne de redirections et évalue la réponse au regard des principaux en-têtes de sécurité.

Fonctionnement des en-têtes HTTP et des codes de statut

Chaque réponse HTTP commence par un code de statut et un ensemble d'en-têtes, avant le corps de la page. Le code de statut indique au client ce qui s'est passé : 200 signifie un succès, 301 et 302 signalent que la ressource a été déplacée, 404 indique qu'elle est introuvable, et 5xx qu'une erreur est survenue côté serveur. Les en-têtes transportent des métadonnées telles que Content-Type, Server, Cache-Control ainsi que les directives de sécurité qui indiquent au navigateur comment traiter la page. IPeek interroge l'URL, capture ces en-têtes exactement tels que le serveur les a envoyés, et suit chaque redirection pour vous montrer le chemin complet jusqu'à la réponse finale.

Comment lire vos résultats d'en-têtes et de redirections

Vérifiez d'abord que le code de statut final correspond à celui attendu, généralement 200 pour une page en ligne. Parcourez ensuite la chaîne de redirections : une configuration propre redirige HTTP vers HTTPS et tout hôte non canonique vers l'hôte canonique en un minimum de sauts, car chaque redirection supplémentaire ajoute de la latence. Surveillez les boucles de redirection ou les chaînes qui aboutissent sur le mauvais hôte. L'en-tête Server révèle le logiciel utilisé, et la note de sécurité des en-têtes indique d'un coup d'œil quels en-têtes de protection sont présents et lesquels manquent.

En-têtes de sécurité essentiels et lacunes fréquentes

Strict-Transport-Security (HSTS) force les navigateurs à utiliser HTTPS, ce qui empêche les attaques par rétrogradation. Content-Security-Policy restreint les sources depuis lesquelles les scripts et les ressources peuvent être chargés : c'est la meilleure défense contre le cross-site scripting. X-Frame-Options ou la directive frame-ancestors d'une CSP bloque le clickjacking en contrôlant qui peut intégrer votre page. X-Content-Type-Options: nosniff empêche le reniflage de type MIME. La lacune la plus courante est un site qui n'envoie aucun de ces en-têtes, laissant le navigateur sans protection supplémentaire. Ajoutez-les au niveau du serveur web ou du CDN, puis revérifiez qu'ils apparaissent bien dans la réponse en ligne.

Quand effectuer une vérification des en-têtes HTTP

Vérifiez les en-têtes après un déploiement, après un changement de CDN ou de reverse proxy, et chaque fois que vous renforcez la posture de sécurité d'un site, car ce sont les moments où des en-têtes sont ajoutés, supprimés ou écrasés. C'est le moyen le plus rapide de confirmer qu'une redirection HTTP vers HTTPS fonctionne réellement, de déboguer une chaîne de redirections inattendue, ou de vérifier qu'un en-tête de sécurité que vous avez configuré atteint bien les navigateurs réels au lieu d'être supprimé quelque part dans la chaîne de distribution.

Questions fréquentes

Qu'est-ce qu'une vérification des en-têtes HTTP vous apprend ?

Elle affiche le code de statut, la chaîne de redirections, le logiciel serveur et les en-têtes de sécurité renvoyés par un site. Vous voyez si l'URL redirige correctement, combien de sauts cela nécessite, quel serveur répond, et quels en-têtes de protection comme HSTS et Content-Security-Policy sont présents ou manquants. C'est donc un diagnostic rapide à la fois pour les problèmes de routage et pour les failles de sécurité.

Qu'est-ce que le HSTS et pourquoi est-il important ?

HTTP Strict-Transport-Security est un en-tête qui demande aux navigateurs de se connecter uniquement en HTTPS pendant une durée définie. Il est important car il empêche les attaques par rétrogradation et de type man-in-the-middle, où un attaquant force une connexion HTTP non sécurisée. Une fois que le navigateur a vu HSTS, il refuse toute connexion HTTP en clair vers cet hôte jusqu'à l'expiration de la politique, fermant ainsi une véritable fenêtre d'attaque.

Pourquoi mon site a-t-il autant de redirections ?

Les chaînes de redirections s'accumulent généralement lorsque des règles distinctes corrigent chacune un seul point : HTTP vers HTTPS, non-www vers www, et normalisation du slash final. Chaque saut ajoute de la latence et un risque d'erreur. Regroupez-les autant que possible en une seule redirection vers l'URL canonique finale, et surveillez les boucles où deux règles se renvoient la requête en permanence.

Quels en-têtes de sécurité tout site devrait-il avoir ?

Au minimum, envoyez Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, et une protection contre l'intégration via X-Frame-Options ou la directive frame-ancestors d'une CSP. HSTS impose le HTTPS, la CSP limite l'injection de scripts, nosniff empêche la confusion de type MIME, et la protection contre l'intégration bloque le clickjacking. Ensemble, ils couvrent les classes d'attaques côté navigateur les plus courantes avec des directives à définir une seule fois au niveau du serveur ou du CDN.

Quelle est la différence entre une redirection 301 et 302 ?

Une 301 est une redirection permanente et une 302 est temporaire. Une 301 indique aux navigateurs et aux moteurs de recherche que la ressource a été déplacée définitivement, de sorte qu'ils mettent à jour les favoris et transmettent les signaux de classement à la nouvelle URL. Une 302 signale que le déplacement est temporaire, et les clients continuent donc d'utiliser l'URL d'origine. Utilisez une 301 pour les redirections canoniques et vers HTTPS.