← Tous les articles

Comment améliorer votre note de headers de sécurité

CentralCSP Team ·

Dernière mise à jour:

Un scanner vous a donné une note de headers de sécurité basse, et vous cherchez maintenant quels headers poser, et comment. Cette note est un score de checklist : un outil lit vos headers de réponse, coche chaque header recommandé comme présent ou manquant, puis évalue la qualité de configuration de ceux qui sont là. Pour la relever, il faut envoyer le bon jeu de headers avec les bonnes valeurs. Voici ce jeu, le rôle de chaque header et la valeur à déployer, avec les correctifs plus poussés en lien à chaque étape.

Chaque scanner pondère à sa façon. securityheaders.com vérifie une liste fixe de headers et vous dégrade pour ceux qui manquent. Mozilla Observatory (l'Observatory de MDN) note la CSP plus strictement et récompense une politique sans 'unsafe-inline'. Les agences de notation posent leur propre vocabulaire sur les mêmes vérifications. Les headers ci-dessous les couvrent toutes.

Les headers qu'un scanner note

Six headers font presque toute la note. Posez-les, configurez-les correctement, et un A devient atteignable.

La politique de sécurité du contenu, le facteur unique le plus lourd

Une politique de sécurité du contenu (CSP) indique au navigateur quels scripts, styles et autres ressources une page peut charger. C'est le header auquel la plupart des scanners donnent le plus de poids, et une CSP stricte sans 'unsafe-inline' est ce qui décroche la meilleure note sur un scanner qui sait lire la CSP, comme Mozilla Observatory.

Content-Security-Policy:
    default-src 'self';
    script-src 'nonce-{RANDOM}' 'strict-dynamic';
    object-src 'none';
    base-uri 'none';
    frame-ancestors 'none'

Une CSP est aussi le header le plus susceptible de casser la page si vous l'écrivez au jugé : déployez-la d'abord en report-only, collectez ce que le trafic réel bloque, puis appliquez-la. La méthode complète est dans comment construire une CSP solide, étape par étape, et le mot-clé à retirer en premier est traité dans pourquoi ne jamais utiliser unsafe-inline dans une CSP.

Strict-Transport-Security (HSTS), imposer HTTPS

Strict-Transport-Security indique au navigateur de ne joindre votre site qu'en HTTPS, ce qui referme la faille de la toute première requête partie en clair. Envoyez un long max-age et incluez les sous-domaines. N'ajoutez preload que lorsque vous êtes prêt à engager le domaine sur la liste de preload du navigateur, car c'est difficile à annuler.

Strict-Transport-Security: max-age=63072000; includeSubDomains

X-Content-Type-Options, stopper le MIME sniffing

X-Content-Type-Options: nosniff empêche le navigateur de deviner le type de contenu déclaré d'une réponse, ce qui est justement ainsi que certains fichiers uploadés finissent exécutés comme des scripts. Il n'a qu'une seule valeur et aucun remplaçant moderne : posez-le partout.

X-Content-Type-Options: nosniff

Contrôle du framing, préférez frame-ancestors

La protection anti-clickjacking décide qui peut embarquer votre page dans une frame. Le contrôle moderne est la directive CSP frame-ancestors, qui gère plusieurs origines et 'none'. L'ancien header X-Frame-Options satisfait encore certaines vérifications de scanner et sert de repli pour les navigateurs très anciens, mais c'est frame-ancestors qui fait le travail aujourd'hui. Les raisons de la disparition de l'ancien header sont détaillées dans les headers de sécurité hérités que vous pouvez retirer.

Content-Security-Policy: frame-ancestors 'none'

Referrer-Policy, limiter ce que vous laissez fuir

Referrer-Policy contrôle quelle part de l'URL courante est envoyée dans le header Referer quand un utilisateur quitte la page ou qu'une page charge une ressource. Une valeur par défaut raisonnable ne transmet que l'origine sur les requêtes cross-origin, et le chemin complet en same-origin.

Referrer-Policy: strict-origin-when-cross-origin

Permissions-Policy, désactiver les fonctionnalités que vous n'utilisez pas

Permissions-Policy contrôle l'accès aux fonctionnalités du navigateur comme la caméra, le microphone et la géolocalisation. Désactiver celles que votre site n'utilise pas réduit ce qu'un script injecté peut atteindre. C'est le successeur standardisé du Feature-Policy déprécié, expliqué dans Permissions-Policy expliqué.

Permissions-Policy: geolocation=(), camera=(), microphone=()

L'ordre dans lequel les corriger

Posez d'abord les headers à faible risque, car ils ne peuvent pas casser la page : X-Content-Type-Options, Referrer-Policy, Strict-Transport-Security et Permissions-Policy sont des ajouts d'une ligne que vous pouvez déployer aujourd'hui. Ils feront bouger la note immédiatement.

Gardez la CSP pour la fin : c'est la seule qui exige le cycle report-only, collecte, application, pour ne pas casser le trafic réel. C'est aussi le critère qui pèse le plus lourd, elle mérite donc ce soin supplémentaire.

Si votre note basse vient d'une agence de notation

Les agences de notation de sécurité évaluent les mêmes headers, mais publient leurs propres noms de findings ; le correctif, lui, reste le même jeu de headers bien configuré. Si votre finding vient de l'une d'elles, les guides par agence rattachent chaque finding à un changement de header :

Comparaisons directes

Plusieurs de ces headers ont un cousin proche avec lequel on les confond. Quand vous hésitez entre les deux, ces comparaisons détaillent le compromis :

Pour la référence complète sur chaque header, voyez la documentation des headers de sécurité.

Voyez d'abord votre état actuel

Avant de changer quoi que ce soit, scannez ce que le site en ligne envoie. Un scan liste les headers présents, ceux qui manquent et ceux qui portent des valeurs faibles : de quoi corriger en une seule passe, au lieu d'avancer à l'aveugle. Le scanner de headers de sécurité vous donne cette liste, le scanner CSP détaille la politique elle-même, et l'évaluateur CSP note un brouillon de politique avant que vous ne le déployiez. Une fois les headers en place, la suite CSP collecte les rapports de violation et suit la politique dans le temps pour que la note ne glisse pas discrètement après le prochain déploiement.

Où cela vous mène

Une note de headers de sécurité est une checklist, et la relever en est une aussi : envoyez X-Content-Type-Options, Referrer-Policy, Strict-Transport-Security et Permissions-Policy maintenant, puis construisez et appliquez une CSP stricte avec frame-ancestors pour la part la plus lourde du score. Scannez d'abord pour connaître votre point de départ, et continuez à scanner pour qu'un nouveau script tiers ne défasse pas le travail.

Pour collecter les rapports de violation, suivre votre politique dans le temps et surveiller les headers sur tout votre parc, démarrez gratuitement avec CentralCSP.

Sources

Articles liés