Vérificateur d'en-têtes de sécurité

Le Vérificateur d'En-têtes de Sécurité est un outil en ligne gratuit dans lequel vous collez les en-têtes de réponse HTTP pour analyser la configuration de sécurité avec une notation, des vérifications CSP/HSTS/cookies et une analyse des politiques cross-origin. Il fonctionne entièrement dans votre navigateur, sans installation ni inscription.

CSP, HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, COOP/COEP/CORP, X-XSS-Protection, Cache-Control et les indicateurs de sécurité Set-Cookie.

Chaque en-tête est pondéré selon sa gravité. Une configuration correcte obtient le poids total, une mauvaise configuration une partie, et une absence un zéro. Le total correspond à une note de A+ à F.

Oui. Toute l'analyse s'exécute dans votre navigateur. Aucune donnée n'est envoyée à un serveur.

Oui, le Vérificateur d'En-têtes de Sécurité est 100 % gratuit, sans inscription, sans frais cachés et sans limite d'utilisation. Tout le traitement se fait localement dans votre navigateur, garantissant une confidentialité totale.

Oui, le Vérificateur d'En-têtes de Sécurité est entièrement responsive et fonctionne sur smartphones et tablettes. Vous pouvez l'utiliser sur n'importe quel appareil doté d'un navigateur web moderne, sans aucune application à télécharger.

Aucun compte ni inscription n'est nécessaire. Ouvrez simplement le Vérificateur d'En-têtes de Sécurité dans votre navigateur et utilisez-le immédiatement. Il n'y a ni barrière d'inscription ni restriction d'utilisation.

Saisissez simplement vos données dans le champ prévu, ajustez les paramètres selon vos préférences, et l'outil les traitera instantanément. Vous pouvez ensuite copier le résultat dans le presse-papiers ou le télécharger.

Le Vérificateur d'En-têtes de Sécurité fonctionne dans tous les navigateurs modernes, dont Chrome, Firefox, Safari, Edge et Opera. Pour une expérience optimale, utilisez la dernière version de votre navigateur préféré.

Il existe deux méthodes rapides. Depuis la ligne de commande, exécutez curl -I https://example.com et copiez la réponse, qui affiche chaque en-tête sur sa propre ligne. Depuis le navigateur, ouvrez les DevTools, passez à l'onglet Network, rechargez la page, cliquez sur la requête principale du document tout en haut, puis copiez la section Response Headers. Dans les deux cas, collez les lignes dans la zone au format Clé: Valeur, un en-tête par ligne. La ligne de statut initiale, comme HTTP/2 200 OK, peut être laissée telle quelle, elle est ignorée automatiquement. Comme curl et les DevTools récupèrent la page en tant que véritable client, ils capturent exactement les en-têtes reçus par un navigateur, y compris Set-Cookie et les directives de cache. Si vous voulez simplement voir comment fonctionne la notation, chargez plutôt l'exemple intégré Sécurisé ou Faible et examinez le détail par en-tête.

Un en-tête HSTS solide indique aux navigateurs de ne se connecter qu'en HTTPS pendant une longue durée et de couvrir tous les sous-domaines. Le vérificateur recherche trois éléments : un max-age d'au moins 31536000 secondes (un an), la directive includeSubDomains pour que les sous-domaines héritent de la même règle HTTPS uniquement, et l'indicateur preload. Un max-age court, de quelques jours par exemple, laisse une longue fenêtre pendant laquelle une attaque de rétrogradation ou de type man-in-the-middle peut supprimer le HTTPS ; l'outil signale donc toute valeur inférieure à un an et affiche la valeur en jours. L'indicateur preload compte car il rend votre domaine éligible aux listes de préchargement HSTS intégrées à Chrome, Firefox et Safari, qui imposent le HTTPS dès la toute première visite d'un utilisateur. Collez vos en-têtes pour voir précisément lequel de ces trois éléments manque à votre HSTS.

Les deux protègent contre le clickjacking en contrôlant si votre page peut être intégrée dans une iframe, mais frame-ancestors est le remplacement moderne. X-Frame-Options est plus ancien et ne prend en charge de façon fiable que DENY et SAMEORIGIN ; sa valeur ALLOW-FROM est dépréciée et ignorée par Chrome, Firefox et Safari, c'est pourquoi le vérificateur la marque comme mal configurée. La directive frame-ancestors de la Content-Security-Policy remplit le même rôle mais de façon plus souple : elle accepte une liste d'origines autorisées et est prise en charge de manière cohérente par les navigateurs actuels. La bonne pratique consiste à déployer frame-ancestors 'none' ou une liste d'autorisation précise dans votre CSP, et à ne garder X-Frame-Options: SAMEORIGIN que comme solution de repli pour les très anciens navigateurs. L'outil détecte une directive frame-ancestors manquante dans votre CSP et la signale séparément. Collez vos en-têtes pour confirmer que votre protection contre le clickjacking couvre bien les deux niveaux.

Cela peut sembler contre-intuitif, mais 0 est bien la valeur moderne correcte. X-XSS-Protection activait un ancien auditeur XSS intégré aux navigateurs plus anciens, mais cet auditeur comportait des contournements connus et pouvait même être détourné pour désactiver sélectivement certaines parties d'une page ou révéler la présence de certains contenus. Les navigateurs modernes l'ont entièrement supprimé, si bien qu'une valeur comme 1; mode=block n'a plus aucun effet utile et peut donner un faux sentiment de sécurité. Envoyer explicitement X-XSS-Protection: 0 désactive tout comportement hérité résiduel dans les navigateurs qui reconnaissent encore cet en-tête. La véritable défense contre les attaques XSS aujourd'hui repose sur une Content-Security-Policy stricte qui bloque les scripts en ligne et non fiables, ce qui explique pourquoi l'outil accorde un poids important à la CSP et traite cet en-tête comme déprécié. Collez vos en-têtes pour voir si votre CSP fait bien ce travail à votre place.

Le vérificateur examine chaque en-tête Set-Cookie à la recherche de trois indicateurs : Secure, HttpOnly et SameSite. Secure garantit que le cookie n'est envoyé que sur HTTPS, il ne peut donc pas être intercepté sur une connexion non chiffrée. HttpOnly cache le cookie à JavaScript, ce qui empêche une charge XSS de dérober un jeton de session via document.cookie. SameSite contrôle si le cookie est envoyé lors de requêtes intersites ; Strict ou Lax aide à bloquer les attaques de type CSRF, tandis que None exige la présence de Secure. Les cookies de session et d'authentification devraient porter les trois, et l'outil signale tout cookie auquel il en manque, afin que vous sachiez lesquels exposent un utilisateur. Comme tout est analysé dans votre navigateur, vous pouvez coller sans risque des réponses authentifiées contenant de véritables valeurs Set-Cookie. Collez vos en-têtes pour obtenir la liste, cookie par cookie, des indicateurs présents et absents.