Vérifier les en-têtes de sécurité
Saisissez une adresse. Vous obtenez les six en-têtes qui comptent, chacun avec ce que sa valeur obtient réellement — et ceux qui sont là sans rien faire sont signalés.
Pourquoi « présent » n’est pas une note
Tous les autres vérificateurs notent la présence : l’en-tête est là, vert. Mais un en-tête peut être là et ne rien faire du tout — max-age=0 est la façon documentée de désactiver HSTS, une politique en mode Report-Only signale et ne bloque pas, et frame-ancestors fait que le navigateur ignore complètement votre X-Frame-Options. Les trois se lisent comme faites. Et c’est pire qu’un en-tête absent, car un en-tête qu’on voit est un en-tête qu’on cesse de vérifier.
Ce que cela ne vous dit pas
Si votre site est sûr. Ces en-têtes limitent ce qu’une attaque peut faire une fois que quelque chose a mal tourné ; ils ne font rien contre la faille qui l’a laissée entrer. Un six parfait ici cohabite très bien avec un CMS jamais mis à jour.
Si vous êtes ici, voici ce qui vient généralement ensuite
Une photo, ou le film entier
Voilà l’état du site à cet instant. La surveillance le regarde — le certificat, le DNS, la disponibilité — et vous prévient le jour où quelque chose change, en général le jour où quelqu’un a déployé une configuration qu’il n’a pas lue.
Questions fréquentes
- Il dit que mon en-tête ne fait rien. Je le vois pourtant dans la réponse.
- Nous aussi, et c’est tout le sujet. Trois d’entre eux traînent en permanence, présents et inertes : HSTS avec max-age=0 (c’est l’ordre de l’oublier), une Content-Security-Policy envoyée seulement en Report-Only (elle signale, elle ne bloque pas), et un X-Frame-Options sur un site dont la politique porte aussi frame-ancestors, à laquelle le navigateur obéit. La valeur figure dans le rapport ; comparez-la à ce que vous croyiez avoir posé.
- Faut-il les six ?
- Cinq tiennent en une ligne de configuration chacun et il n’y a aucune raison de s’en passer. La Content-Security-Policy est celle qui demande un vrai travail, car une politique stricte casse vos scripts en ligne jusqu’à ce que vous les repreniez — et c’est aussi la seule qui limite les dégâts d’un XSS au lieu d’espérer l’empêcher. Celle-là se déploie d’abord en Report-Only, on lit les rapports, puis on l’active.
- Pourquoi unsafe-inline pose problème si le reste est verrouillé ?
- Parce que c’est précisément ce qu’une CSP existe pour empêcher. Avec unsafe-inline dans script-src, une balise script injectée s’exécute — et c’est toute l’attaque. Tout le reste de ce que la politique restreint vaut moins que cette seule brèche. La sortie, ce sont les nonces ou les empreintes, et strict-dynamic vous laisse garder unsafe-inline comme repli pour les vieux navigateurs sans que cela compte contre vous.