Vérifier les en-têtes de sécurité HTTP : onze outils comparés

Date de relevé : 26 octobre 2026. Chaque ligne du tableau ci-dessous a été vérifiée sur la page de l'outil ce jour-là, et chaque lien mène à la source. Les deux mesures faites par nous-mêmes sont signalées comme telles. Cette page range les outils par usage. Deux d'entre eux ne répondent pas à la même question, donc un classement unique n'aurait pas de sens.

Trois questions que l'on confond#

Trois travaux différents se cachent derrière "vérifier les en-têtes". Le plus courant regarde si l'en-tête est là : Content-Security-Policy, Strict-Transport-Security, X-Frame-Options et les autres. C'est ce que font la majorité des outils, avec une note en lettre à la clé. Un cran plus loin, on vérifie la valeur : la politique envoyée protège-t-elle vraiment, ou autorise-t-elle n'importe quel script ? Reste le contexte, que presque personne ne traite : ce site a-t-il quelque chose à protéger à cet endroit, et quelle ligne de configuration écrire dans sa pile ?

Presque tous s'arrêtent au premier contrôle. Une poignée va jusqu'à la valeur. Le contexte, lui, n'est traité nulle part, et c'est pourtant lui qui décide si l'en-tête manquant vous concerne.

Le tableau#

Le classement par usage#

securityheaders.com reste le plus rapide pour un diagnostic en anglais : vous collez une URL, vous obtenez six en-têtes et une lettre. Il ne lit ni les cookies ni le TLS, et il ne fait pas baisser la note quand la CSP autorise unsafe-inline.

Si ce qui vous intéresse est la valeur et pas la présence, ssl.org affiche les valeurs brutes et qualifie chacune, sans note ; CentralCSP fait de même avec un score sur 100 et un correctif par constat. Ce sont les deux seuls du tableau à qualifier chaque en-tête d'un scan d'URL sans rendre une note globale.

En français, Kreio classe par gravité et donne une note A à F ; CheckCyber donne un score sur 100 et des exemples de configuration Apache et nginx. CheckCyber est le plus concret sur la remise en état. Kreio se lit plus vite quand il faut décider par quoi commencer.

Pour suivre une CSP dans le temps, CSP Evaluator juge la politique avant déploiement ; Report URI collecte les violations en production, mais c'est un abonnement à partir de 54,99 dollars US par mois, pas un outil gratuit. CentralCSP vend le même suivi.

Un certificat TLS se vérifie chez Qualys SSL Labs, référence depuis 2009 ; ImmuniWeb y ajoute la conformité et la disponibilité post-quantique. Quant à la vue complète, Hardenize couvre DNS, mail, TLS et en-têtes, et qualifie chaque constat par l'importance qu'il a pour votre type de site. Pour une méthode publiée et une interface en français, MDN HTTP Observatory : sa documentation de score est publique, ce qui permet de dire d'où vient la note avant de la citer.

Ce qu'aucun de ces outils ne fait#

1. La note est un jugement, pas une mesure, et Mozilla l'écrit. Traduction de la documentation de l'Observatory : "il est difficile d'attribuer une valeur objective à une question subjective, du type : à quel point est-il grave de ne pas implémenter HSTS ?" Le même texte ajoute que "les plages de notes et les modificateurs sont essentiellement arbitraires". Une note A-F est donc une opinion calibrée, pas un fait reproductible. Elle reste utile pour se situer. Elle ne tient pas devant un client qui demande une preuve.

2. Le contexte du site n'entre pas dans le calcul. Un site vitrine de cinq pages, sans formulaire, sans connexion et sans donnée personnelle n'a presque rien à protéger là où la grille retire des points. Mozilla le reconnaît : ce qui est inutile pour un site peut réduire un risque important pour un autre. Hardenize est le seul du tableau à nuancer ses constats par type de site ; aucun ne demande si votre site a un formulaire de connexion avant de vous donner une lettre.

3. "Présent" n'est pas "efficace", et deux outils peuvent se contredire le même jour. Nous avons scanné breachvex.com le 26 octobre 2026 à 16:34 UTC. securityheaders.com rend A, avec un avertissement indiquant que la politique contient unsafe-inline et unsafe-eval dans script-src et que la note est plafonnée à A. Le même domaine, dix secondes plus tard, sur MDN HTTP Observatory : B, 75 sur 100, 10 tests sur 12, avec -20 points sur le test CSP pour exactement la même raison. Une politique qui autorise les scripts en ligne n'est pas une protection contre l'injection, et l'un des deux outils la récompense quand même. À l'échelle du web, 46,8 % des 170 057 politiques CSP du top 1 million contiennent unsafe-inline (Report URI, instantané du 13 juin 2026). C'est un autre corpus que celui de l'étude citée plus bas, sur un autre périmètre.

4. Aucun ne dit ce qui va casser chez vous. Plusieurs donnent un correctif : CheckCyber des exemples Apache et nginx, CentralCSP la valeur exacte à déployer. Aucun ne sait que votre page charge Google Tag Manager, un iframe de paiement et un script inline généré par votre framework, ni que passer en Report-Only puis en nonce va casser l'un des trois. La ligne de configuration pour votre pile réelle, avec l'avertissement sur ce qu'elle casse, n'est dans aucun de ces rapports.

5. Aucun ne produit un rapport que l'on peut remettre à un tiers. Plusieurs affichent une version de leur moteur, mais aucun ne fournit une attestation : un périmètre énoncé, une version de méthode et une durée de validité que vous pouvez joindre à une réponse à un client ou à un assureur.

6. Un scan ne voit qu'une URL. Une CSP peut être servie sur une route et pas sur une autre, et deux serveurs derrière un CDN peuvent répondre différemment. ssl.org est le seul à l'écrire sur sa page, et il répond en laissant scanner une autre URL, pas en qualifiant son propre verdict. Les autres ne le mentionnent pas.

Méthode#

Relevé du 26 octobre 2026. Pour chaque outil : lecture de la page publique (présentation, FAQ, tarifs, documentation de score) et, quand elle existe, de sa page de méthodologie. Les liens du tableau pointent vers ces pages.

Deux scans réels ont été faits le même jour sur un domaine que nous contrôlons, breachvex.com, sur securityheaders.com et sur MDN HTTP Observatory, pour comparer deux grilles sur une configuration identique.

Ce que nous n'avons pas fait : aucun test de faux positifs à grande échelle, aucune comparaison de vitesse, aucun audit du code de ces outils, aucun test des versions payantes. Les colonnes "ce qu'il ne mesure pas" viennent des pages publiques et de nos scans, pas d'une campagne de mesure. Quand un point n'a pas pu être vérifié sur la page de l'outil, il n'a pas été deviné pour autant : la limite est nommée dans la ligne concernée.

Ce que nous faisons, et ce que nous ne prétendons pas#

BreachVex édite un pentest applicatif automatisé. La promesse tient en une phrase : un résultat n'entre dans la file prioritaire que si l'exploit a été exécuté. Nous n'avons pas d'outil d'en-têtes publié à ce jour, et cette page ne le remplace pas : elle existe parce que la question revient assez souvent, et parce que deux outils venaient de nous contredire le même jour sur notre propre site. Tout ce qui précède a été mesuré, relu sur la page de l'outil ou reproduit par une commande ; le reste est signalé comme non vérifié.

Trois choses que nous ne prétendons pas. Nous ne remplaçons ni Report URI pour le suivi des violations CSP, ni Qualys SSL Labs pour l'analyse TLS, ni MDN HTTP Observatory pour une note institutionnelle. Nous ne prouvons pas d'exploitation à partir d'un en-tête manquant : un en-tête absent est une exposition, pas une faille démontrée. Et un scanner ne remplace pas un audit.

Si cette page vous a servi, dites-nous quel outil vous a donné un résultat que vous avez jugé faux, et sur quel site. C'est ce qui améliorera la prochaine version de ce relevé.