Consultez les Security Headers HTTP réellement envoyés par un site et identifiez ceux qui manquent, qui sont vulnérables ou qui s'annulent mutuellement sans que l'on s'en aperçoive. Gratuit, sans inscription.
Les Security Headers sont des instructions qu’un serveur web envoie avec chaque réponse afin d’activer les protections dont dispose déjà le navigateur : quelles sources sont autorisées à exécuter des scripts, si le site peut être chargé via le protocole HTTP en clair, et si un autre site peut l’intégrer dans un cadre. L’outil « ReportedIP Security Header Check » analyse ces en-têtes, évalue chacun d’entre eux en fonction de ce qu’il empêche concrètement, et identifie la modification spécifique à apporter pour chaque faille.
La plupart des outils de vérification d’en-têtes vous fournissent une liste de contrôle et une note. Cela revient à considérer qu’un en-tête Permissions-Policy manquant pose le même problème qu’un en-tête Content-Security-Policy manquant, ce qui n’est pas le cas. L’un limite les capacités de l’API du navigateur ; l’autre fait la différence entre l’exécution ou non d’un script intersite.
Ce contrôle évalue chaque en-tête en fonction de ce qu’il empêche. Le Content-Security-Policy compte le plus, suivi de l’HSTS, puis de la protection contre le framing et de la détection du type de contenu. Les en-têtes d’isolation inter-origines sont signalés mais notés zéro, car un site qui n’en a jamais eu besoin ne devrait pas perdre de points pour cela.
Un site doté d’une Content-Security-Policy correcte n’a pas besoin de l’ancien en-tête, et exiger les deux relève d’un conseil datant d’il y a dix ans. Une politique de type « report-only » ne compte pas, car les navigateurs ne l’appliquent pas.
Cela indique activement au navigateur d’oublier que le site a jamais été exclusivement en HTTPS. Une liste de contrôle détecte la présence de cet en-tête et coche la case correspondante.
Les navigateurs l’ignorent dans ce cas ; la vérification l’exclut donc du calcul au lieu de retirer des points pour cela.
La page est récupérée via une requête GET normale, et non HEAD, car certains serveurs répondent différemment à ces deux requêtes et ce sont les en-têtes que le navigateur voit qui comptent. Seuls les en-têtes de réponse sont inspectés ; le contenu de la page n’est pas stocké.
L’adresse est récupérée à l’aide d’une requête GET standard, suivie de trois redirections au maximum, puis les en-têtes de réponse sont analysés. On utilise GET plutôt que HEAD, car un nombre non négligeable de serveurs, de proxys inversés et de pare-feu traitent les requêtes HEAD via un chemin d’exécution différent, avec un ensemble d’en-têtes plus restreint, ce qui ferait apparaître comme manquants des en-têtes que le navigateur réel reçoit bel et bien. La vérification est effectuée à partir de ce serveur ; par conséquent, un site qui adapte ses en-têtes en fonction du pays, de l’agent utilisateur ou du statut de Login peut vous renvoyer une réponse différente.
Le score est pondéré, il ne s’agit pas d’un simple décompte. Les en-têtes « Content-Security-Policy » et « Strict-Transport-Security » ont le plus de poids, car ils déterminent si un script injecté s’exécute et si une requête peut être redirigée vers le protocole HTTP standard. Les en-têtes « Referrer-Policy » et « Permissions-Policy » limitent les fuites d’informations et ont moins de poids. Les entités COOP, COEP et CORP n’ont aucun poids : elles servent à isoler les pages nécessitant des temporisateurs à haute résolution, et un site qui n’en a pas besoin n’est pas moins sécurisé pour autant s’il ne les utilise pas.
L’en-tête X-Frame-Options n’est pas signalé comme manquant lorsque la politique de sécurité du contenu (Content-Security-Policy) définit le paramètre « frame-ancestors ». « frame-ancestors » est le successeur désigné, tous les navigateurs actuels le respectent, et il permet de désigner individuellement les origines autorisées, ce que l’en-tête X-Frame-Options n’a jamais pu faire. Une politique de sécurité du contenu (Content-Security-Policy) envoyée uniquement sous la forme « Report-Only » est traitée comme ce qu’elle est : un instrument de mesure qui enregistre les violations sans rien bloquer.
Une seule page est analysée. Les en-têtes sont généralement définis au niveau du serveur ou du proxy et s’appliquent donc partout, mais une application peut les ajouter ou les supprimer pour chaque route ; il est donc plus pertinent de vérifier la page qui compte, à savoir la page de Login ou celle de paiement, plutôt que la page d’accueil. L’outil ne lit que les en-têtes et n’inspecte jamais le contenu de la page ; il ne peut donc pas déterminer si une politique est réellement suffisamment large pour permettre le bon fonctionnement du site.