Pour vérifier les en-têtes de sécurité d’un site, demandez la page en HTTPS et lisez six en-têtes de réponse : Strict-Transport-Security, Content-Security-Policy, X-Frame-Options (ou la directive CSP frame-ancestors), X-Content-Type-Options, Referrer-Policy et Permissions-Policy, sans oublier les attributs de chaque Set-Cookie. Un en-tête absent n’est pas forcément une faille, et un en-tête présent ne prouve rien : c’est la valeur qui compte. Notre outil gratuit d’en-têtes HTTP affiche tous les en-têtes d’une URL en quelques secondes, sans compte.
Tous les résultats de ce guide proviennent de tests réels faits le 3 novembre 2026 avec notre outil sur GitHub, la BBC et example.com. Les règles viennent de MDN, des critères officiels de la liste de préchargement HSTS et de la RFC 6797, vérifiés le même jour.
Vous avez déjà l’URL ? Collez l’adresse complète, avec https://, dans l’outil gratuit d’en-têtes HTTP et gardez le résultat ouvert pendant que vous lisez la liste ci-dessous.
Les six en-têtes qui comptent et la bonne valeur pour chacun
| En-tête | Ce qu’il empêche | Une valeur solide | Erreur fréquente |
|---|---|---|---|
Strict-Transport-Security | Le retour forcé en HTTP non chiffré et le vol de cookie sur un Wi-Fi public | max-age=31536000; includeSubDomains | Un max-age court, ou l’envoyer seulement sur la redirection HTTP |
Content-Security-Policy | Les scripts injectés (XSS) et la fuite de données | Part de default-src 'self' ou 'none' et liste les vraies sources | 'unsafe-inline' dans script-src, ou des jokers |
X-Frame-Options / frame-ancestors | Le clickjacking (votre page dans l’iframe d’un autre site) | DENY, SAMEORIGIN ou frame-ancestors 'self' | L’oublier sur la connexion et le paiement |
X-Content-Type-Options | Le navigateur qui prend un fichier texte pour un script | nosniff (seule valeur valide) | Aucune : c’est un seul mot |
Referrer-Policy | La fuite d’URL complètes, de jetons et de recherches vers d’autres sites | strict-origin-when-cross-origin ou plus strict | Fixer l’ancienne no-referrer-when-downgrade |
Permissions-Policy | Un tiers intégré qui utilise caméra, micro ou position | camera=(), microphone=(), geolocation=() si vous ne vous en servez pas | L’omettre sur des pages pleines de widgets externes |
Un en-tête que vous pouvez oublier : X-XSS-Protection. MDN avertit qu’il peut créer des failles XSS sur des sites par ailleurs sûrs et recommande plutôt une Content-Security-Policy. C’est pour cela que GitHub envoie x-xss-protection: 0 : il désactive volontairement l’ancien filtre.
Vérifier les en-têtes de sécurité étape par étape
1. Prenez l’URL exacte où arrivent les visiteurs
Saisissez l’adresse complète avec le schéma : https://github.com/, pas github.com. Avec le domaine seul, notre outil a affiché un message de champ obligatoire au lieu d’un résultat, car il a besoin du schéma pour savoir quoi demander. Vérifiez l’accueil, mais aussi la connexion, les formulaires et le paiement : ils sont souvent servis par une autre application, avec d’autres en-têtes.
2. Lancez la vérification
Ouvrez l’outil d’en-têtes HTTP, collez l’URL et cliquez sur le bouton. La requête part de notre serveur : vous voyez ce que reçoit n’importe quel visiteur, sans les extensions ni le cache de votre navigateur. C’est gratuit et sans compte ; sans inscription vous avez 5 vérifications par jour, et un compte gratuit (sans spam) lève cette limite.
3. Repérez le bon saut
L’outil suit les redirections et regroupe dans un seul tableau les en-têtes de tous les sauts. La première ligne affiche le statut de la première réponse. Pour http://github.com, le tableau commençait par HTTP/1.1 301 Moved Permanently et Location: https://github.com/, et tout le reste venait de la page HTTPS finale. La règle : ce qui se trouve sous la dernière ligne Location appartient à la page que voient les gens. Pour un tableau propre, testez directement l’URL HTTPS finale et utilisez le vérificateur de redirections pour voir le code de chaque saut.
4. Comparez chaque en-tête au tableau
Passez les six lignes ci-dessus en revue. Notez ce qui manque, puis lisez la valeur de ce qui est présent : une valeur faible est un problème plus courant qu’un en-tête absent.
5. Lisez les attributs des cookies
Toutes les lignes Set-Cookie apparaissent ensemble sur une ligne. Un cookie de session doit porter Secure, HttpOnly et une valeur SameSite. Un cookie de mesure d’audience peut se passer de HttpOnly volontairement, puisque des scripts doivent le lire.
Exemple 1 : GitHub, la référence solide
La vérification de https://github.com/ a renvoyé HTTP/2 200 et ces lignes de sécurité (CSP raccourcie) :
strict-transport-security: max-age=31536000; includeSubdomains; preload
x-frame-options: deny
x-content-type-options: nosniff
x-xss-protection: 0
referrer-policy: origin-when-cross-origin, strict-origin-when-cross-origin
content-security-policy: default-src 'none'; base-uri 'self'; child-src github.githubassets.com ...- La CSP part de
default-src 'none': rien ne se charge sans une directive qui l’autorise. C’est le point de départ le plus strict, à reprendre pour un nouveau site. - La Referrer-Policy est une liste. MDN la décrit comme une politique de repli : le navigateur applique la dernière valeur qu’il comprend, donc les navigateurs actuels utilisent
strict-origin-when-cross-origin. - Chaque cookie a les attributs adaptés à son rôle.
_gh_sessetlogged_inportentHttpOnly; secure; SameSite=Lax;_octoportesecure; SameSite=LaxsansHttpOnly, logique pour une valeur lue par des scripts.
Pas de Permissions-Policy. Même les sites très soignés n’envoient pas tout : servez-vous de la liste comme d’un guide, pas d’une note.
Exemple 2 : la BBC, des en-têtes présents mais faibles
La vérification de https://www.bbc.com/ a montré :
referrer-policy: no-referrer-when-downgrade
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
strict-transport-security: max-age=31536000; preloadEn survolant, quatre sur six. En lisant de près, deux vrais problèmes :
- La politique de referrer est plus faible que celle du navigateur par défaut. D’après MDN, sans politique définie le navigateur applique
strict-origin-when-cross-origin, etno-referrer-when-downgradeétait l’ancienne valeur par défaut. En fixant l’ancienne valeur, le navigateur envoie l’URL complète, chemin et paramètres compris, à tout autre site HTTPS ; sans l’en-tête, il n’enverrait que l’origine. - Le site demande le préchargement HSTS sans pouvoir y prétendre. hstspreload.org exige
includeSubDomainsavecpreloadet un max-age d’au moins un an sur le domaine de base. Nous avons aussi testéhttps://bbc.com/: il répond par un 301 vers www avec le mêmemax-age=31536000; preload, sansincludeSubDomains.
Pas de Content-Security-Policy non plus. Sur une page avec publicités et nombreux scripts tiers, c’est le plus gros manque, et le plus difficile à combler.
Exemple 3 : example.com, rien du tout
https://example.com/ a renvoyé HTTP/2 200 avec la date, le type de contenu, server: cloudflare, des lignes de cache et aucun en-tête de sécurité. Demandé en http:// depuis notre serveur, il a répondu HTTP/1.1 200 OK sans rediriger vers HTTPS. Sur un vrai site, ce serait la première chose à corriger ; sur une page statique de documentation, sans connexion, cookies ni formulaires, le risque est faible. C’est la règle du contexte : une CSP absente sur une page vitrine n’a pas le même poids que sur la page de paiement d’une boutique.
Les pièges qui faussent la vérification
- HSTS sur la redirection HTTP ne compte pas. MDN et la RFC 6797 indiquent que le navigateur ignore
Strict-Transport-Securityreçu en HTTP non chiffré. Le sauthttp://de GitHub n’envoie que le 301 etLocation; l’en-tête arrive avec la page HTTPS, ce qui est correct. - Un 302 de HTTP vers HTTPS fonctionne, mais un 301 est plus propre.
http://www.bbc.com/a répondu302 Foundethttp://github.com/301. Les deux mènent au HTTPS ; c’est HSTS qui supprime cette première requête non sécurisée lors des visites suivantes. Notre guide pour savoir si une redirection est en 301 ou en 302 détaille la différence. Content-Security-Policy-Report-Onlyne bloque rien. Il signale seulement : le site teste une politique, il n’est pas protégé par elle.- Le CDN peut ajouter ou retirer des en-têtes. Si votre serveur les définit et que l’outil ne les montre pas, regardez les règles du CDN avant d’accuser l’application.
- Une balise meta n’est pas un en-tête. Une CSP posée avec
<meta http-equiv>n’apparaît pas ici et ne prend pas en chargeframe-ancestors. Pour voir le contenu du HTML, utilisez le vérificateur de balises meta. - De bons en-têtes ne prouvent pas qu’un site est fiable. Une page d’hameçonnage peut les envoyer parfaits. Pour juger un site inconnu, suivez notre guide pour savoir si un site est fiable et regardez le certificat avec la vérification SSL.
Une base raisonnable pour votre propre site
Pour un site classique servi uniquement en HTTPS, voici une première version sûre. Testez-la sur une préproduction et déployez la CSP d’abord en Report-Only :
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Content-Security-Policy: default-src 'self'; frame-ancestors 'self'; object-src 'none'; base-uri 'self'N’ajoutez includeSubDomains que lorsque tous les sous-domaines fonctionnent en HTTPS, et attendez d’être sûr avant preload, car sortir de la liste de préchargement prend du temps. Repassez ensuite l’URL dans l’outil gratuit d’en-têtes et vérifiez que chaque ligne est arrivée telle quelle.
Questions fréquentes
Comment vérifier les en-têtes de sécurité gratuitement ?
Collez l’URL complète, avec https://, dans l’outil d’en-têtes HTTP de My Botsy. Il liste tous les en-têtes de réponse en quelques secondes et sans compte. Vous pouvez aussi lancer curl -sI suivi de l’URL dans un terminal, ou ouvrir les outils de développement du navigateur, onglet Réseau, et cliquer sur la requête de la page.
Quels en-têtes de sécurité tout site devrait-il avoir ?
Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options à nosniff, une Referrer-Policy et une protection contre l’intégration en iframe via X-Frame-Options ou frame-ancestors. Permissions-Policy est utile si vous intégrez des contenus tiers. X-XSS-Protection est obsolète : mettez 0 ou ne l’envoyez pas.
Pourquoi l’outil affiche-t-il d’abord un 301 ?
Parce qu’il suit les redirections et regroupe tous les sauts dans un tableau ; la première ligne est le statut de la première réponse. Ce qui suit la dernière ligne Location appartient à la page finale. Testez directement l’URL HTTPS finale pour un résultat propre.
Un site sans Content-Security-Policy est-il dangereux ?
Pas forcément. La CSP limite les dégâts si quelqu’un parvient à injecter un script. Une page statique sans connexion, formulaire ni script tiers a peu à protéger ; une page de connexion ou de paiement sans CSP présente un vrai manque.
Peut-on ajouter des en-têtes de sécurité sans accès au serveur ?
Souvent oui. Les CDN comme Cloudflare permettent d’ajouter des en-têtes de réponse par des règles, et beaucoup d’hébergeurs les acceptent dans le .htaccess ou le panneau d’administration. La CSP peut aussi aller dans une balise meta, mais frame-ancestors ne fonctionne qu’en véritable en-tête.
Les en-têtes de sécurité aident-ils le SEO ?
Leur rôle est de protéger les visiteurs, pas de faire grimper un classement : n’en attendez pas un bond de trafic. Ils apportent de la confiance et de la cohérence : HSTS garde en HTTPS les visiteurs qui reviennent, et une redirection propre de HTTP vers HTTPS fait voir aux moteurs une seule version de chaque page.
