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

Saisissez l'URL d'un site pour vérifier si les en-têtes de sécurité clés comme HSTS, CSP et X-Frame-Options sont correctement configurés. Découvrez quels en-têtes manquent ou sont faibles, avec des conseils pour les corriger.

Astuces

  • Cet outil récupère l'URL cible côté serveur, il peut donc vérifier les en-têtes de n'importe quel site sans se heurter aux restrictions CORS du navigateur.
  • Un max-age HSTS plus long est généralement plus sûr, mais si vous prévoyez de modifier la gestion de votre certificat, testez d'abord avec une valeur plus courte avant de la déployer en production.
  • Associez cet outil au Validateur CSP complémentaire (dev.server.csp_validator) pour vérifier en détail la syntaxe réelle de votre Content-Security-Policy.
  • Cet outil réutilise le même mécanisme "saisir une URL et la récupérer côté serveur" que le vérificateur robots.txt, il peut donc vérifier n'importe quelle page publique sans authentification.
  • Vérifiez régulièrement votre propre site pour vous assurer qu'un changement de configuration d'un CDN ou d'un proxy inverse n'a pas discrètement supprimé un en-tête de sécurité.

Questions fréquentes

Les fonctionnalités sont proches, mais le vérificateur de Toolbase permet de consulter les résultats et les explications de correction en japonais. La vérification détaillée de la syntaxe CSP est prise en charge par l'outil complémentaire Validateur CSP.

Oui, mais comme HSTS n'a de sens que pour les connexions HTTPS, l'élément HSTS sera toujours diagnostiqué comme un échec sur un site uniquement en HTTP. Il faut d'abord prioriser la migration complète du site vers HTTPS.

La directive frame-ancestors de la Content-Security-Policy est actuellement recommandée, mais comme certains anciens navigateurs ne la prennent pas en charge, spécifier les deux comme double couche de protection est la pratique courante.

Non. La requête vers l'URL saisie est effectuée à la volée, et les informations d'en-tête récupérées ne sont jamais stockées sur le serveur.

Pas forcément. Permissions-Policy en particulier est une couche de défense supplémentaire facultative, dont la priorité peut être moindre selon la nature du site. Nous recommandons d'améliorer d'abord les éléments à fort impact comme HSTS, CSP et X-Frame-Options.
ツールくん

Anecdote — securityheaders.com et l'histoire de la défense contre le clickjacking

Le diagnostic des paramètres de sécurité via les en-têtes de réponse HTTP est depuis longtemps dominé par securityheaders.com, créé par Scott Helme. Comme de nombreux services étrangers n'expliquent les résultats et les corrections qu'en anglais, Toolbase a créé son propre vérificateur afin que les résultats et les explications puissent être consultés ensemble en japonais, en tant qu'alternative dans ce domaine.

HSTS (HTTP Strict Transport Security) a été normalisé par l'IETF sous la forme du RFC 6797 en 2012. Son origine remonte à une démonstration de 2009 du "SSL Stripping", une attaque qui exploite le bref instant où un utilisateur saisit une URL sans https:// et où le navigateur se connecte d'abord en HTTP non chiffré, permettant à un attaquant de réécrire le trafic. HSTS permet à un navigateur de retenir que "ce domaine doit toujours être accédé via HTTPS", empêchant ainsi les attaques de rétrogradation après la première visite.

X-Frame-Options était à l'origine un en-tête d'extension propriétaire introduit par Microsoft pour Internet Explorer 8 en 2009, adopté plus tard par d'autres navigateurs jusqu'à devenir un standard de fait. La préoccupation de l'époque était le "clickjacking", où une iframe invisible est superposée à un bouton d'apparence authentique afin que l'utilisateur clique sans s'en rendre compte. Aujourd'hui, le secteur évolue vers la directive frame-ancestors, plus flexible, de la Content-Security-Policy, mais spécifier les deux reste recommandé comme filet de sécurité pour les anciens navigateurs qui ne la prennent pas en charge.

→ Lire les anecdotes connexes

→ Voir toutes les anecdotes

Plus d'outils dans cette catégorie