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.
Diagnostiquer les en-têtes de sécurité d'un site en production
Saisissez une adresse et le serveur se rend sur ce site, en récupère les en-têtes de réponse et juge de la configuration de HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy et Permissions-Policy. Il sépare ce qui manque de ce qui est présent mais faible, et explique dans chaque cas où serait le problème.
**Ce qu'il convient de garder à l'esprit, c'est qu'un en-tête présent et un en-tête efficace sont deux choses distinctes.** HSTS peut fort bien être posé et pourtant, un `max-age` court ne laisse qu'une fenêtre trop brève pendant laquelle le navigateur impose HTTPS, de sorte que la protection réelle demeure mince. Voilà pourquoi cet outil distingue la réussite de l'avertissement. **L'autre point est que les en-têtes qui reviennent n'ont pas forcément été ajoutés par le serveur d'origine.** Un CDN ou un mandataire inverse peut les insérer en chemin, auquel cas l'endroit où corriger la configuration change également. Ce que le diagnostic montre, c'est l'état visible de l'extérieur ; il ne saurait dire quelle couche l'a produit.
Comment s'en servir
- Saisissez l'adresse à examiner Donnez une adresse publiquement joignable commençant par `https://`.
- Lancez le contrôle **Les destinations injoignables de l'extérieur, telles que les adresses IP privées, sont refusées par précaution.**
- Lisez les verdicts Ils viennent en trois degrés — réussite, avertissement et échec — où l'avertissement signifie présent mais faible.
- Appuyez-vous sur les notes pour corriger Chaque entrée porte une explication du défaut, ce qui vous permet d'établir vos priorités.
Astuces pour en tirer le meilleur parti
- 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 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é.
Dans quels cas s'en servir
Pour l'ultime vérification avant publication
Juste avant la mise en ligne, vous confirmez de l'extérieur que les en-têtes prévus sont bien renvoyés.
Pour prendre exemple sur d'autres sites
**Voir jusqu'où sont allés des sites comparables vous donne une mesure de votre propre niveau.**
Pour comparer avant et après une modification
Relancez le contrôle une fois un en-tête ajouté afin de confirmer qu'il a bien pris effet.
Pour inspecter un site dont vous héritez
**Cela convient à l'inventaire qui suit une reprise**, en vous donnant la liste de ce qui manque.
Vocabulaire des en-têtes de sécurité
- HSTS
- Un en-tête contraignant l'accès à passer par HTTPS plutôt que par HTTP. **À moins que `max-age` n'atteigne un an ou davantage, la protection ne dure pas assez.**
- X-Content-Type-Options
- Poser `nosniff` empêche le navigateur de deviner un type MIME d'après le contenu, ce qui évite qu'un fichier soit exécuté pour ce qu'il n'est pas.
- X-Frame-Options
- Un en-tête refusant que votre site soit inséré dans un cadre. **Dans les politiques plus récentes, `frame-ancestors` de CSP assume le même rôle.**
- Content-Security-Policy
- Le mécanisme restreignant la provenance des ressources chargeables. Il constitue la pièce maîtresse de la défense contre le XSS.
- Referrer-Policy
- Un en-tête décidant quelle part de l'adresse de provenance est transmise lorsqu'un visiteur passe sur un autre site.
- Permissions-Policy
- Un en-tête réglant quelles origines peuvent user de fonctions telles que la caméra, le microphone et la localisation.
Questions fréquentes
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.