Ce que vérifie cet outil
Les en-têtes de réponse HTTP sont des instructions que votre serveur envoie à chaque navigateur qui visite votre site, avant même qu'un seul octet de la page ne soit affiché. Certains d'entre eux existent uniquement pour indiquer au navigateur comment protéger le visiteur : ne pas exécuter de scripts en ligne non explicitement autorisés, ne pas laisser cette page être intégrée dans un autre site, ne pas deviner le type d'un fichier à partir de son contenu. Les négliger — ou les oublier — revient à s'appuyer entièrement sur le code de votre application pour couvrir chaque cas particulier, ce qu'il ne fera pas.
Cet analyseur interroge votre page de la même façon qu'un navigateur le ferait, lit les six en-têtes les plus importants pour la sécurité web au quotidien, et note ce qu'il trouve : Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy et Permissions-Policy. Chacun reçoit une explication claire de ce qu'il fait réellement et une valeur concrète à copier s'il est absent ou trop faible — pas seulement une croix rouge.
Pourquoi c'est plus important qu'il n'y paraît
Les en-têtes de sécurité coûtent peu à ajouter (généralement une seule ligne dans la configuration de votre serveur web ou de votre CMS) et ferment des catégories entières d'attaques plutôt que de corriger des bugs isolés. Content-Security-Policy en est le meilleur exemple : même si un attaquant parvient à injecter une balise <script> via un champ de commentaire ou un paramètre non filtré, une CSP correctement configurée empêche le navigateur de l'exécuter. Sans cet en-tête, ce simple point d'injection devient un vecteur de prise de contrôle complète du compte.
Strict-Transport-Security (HSTS) résout un problème différent. Sans lui, la toute première requête d'un visiteur vers example.com (avant même qu'une redirection vers HTTPS ne se déclenche) peut être interceptée sur un Wi-Fi public et silencieusement rétrogradée en HTTP simple. HSTS indique au navigateur de ne plus jamais tenter de connexion non sécurisée pour ce domaine, fermant complètement cette fenêtre — mais seulement une fois que l'en-tête a été vu au moins une fois, ce qui explique l'existence de preload pour les sites qui veulent être protégés dès la toute première visite.
Erreurs courantes détectées par cet outil
CSP avec unsafe-inline. Les équipes l'ajoutent souvent pour débloquer une balise <script> en ligne provenant d'un script d'analyse ou d'une extension WordPress, sans réaliser que cela rouvre exactement le chemin d'injection que la CSP est censée fermer. L'analyseur signale ceci comme un avertissement plutôt qu'une réussite, car cela affaiblit concrètement l'en-tête même s'il est techniquement présent.
HSTS sans includeSubDomains. Un sous-domaine marketing ou un serveur de préproduction oublié en HTTP simple peut toujours être utilisé pour attaquer les visiteurs du site principal si HSTS ne couvre pas les sous-domaines — une faille invisible tant que personne ne la teste spécifiquement.
X-Frame-Options totalement absent. C'est l'en-tête qui empêche votre page de connexion d'être chargée dans un <iframe> invisible sur le site d'un attaquant à des fins de clickjacking. C'est une seule ligne, et il y a rarement une raison légitime de l'omettre, pourtant c'est l'un des en-têtes les plus souvent manquants sur les sites de petite et moyenne taille.
Un exemple concret
Un site WordPress classique, avec un plugin de cache et un CDN devant lui, expose souvent X-Content-Type-Options et une Referrer-Policy basique (définis par les valeurs par défaut du CDN) mais rien d'autre — ce qui donne généralement une note autour de C. Ajouter CSP et HSTS au niveau de la configuration du serveur ou du CDN, sans toucher une seule ligne de PHP, suffit en général pour atteindre un A. Le détail par en-tête sous vos résultats d'analyse sert justement à vous montrer exactement lequel ajouter en premier, pas juste que « quelque chose » ne va pas.