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

Un scanner vous a donné une note de headers de sécurité basse, et vous devez maintenant savoir quels headers poser et comment. La note est un score de checklist : un outil lit vos headers de réponse et marque chaque header recommandé présent ou manquant, puis pèse à quel point ceux qui sont présents sont bien configurés. Pour relever la note, vous envoyez le bon jeu de headers avec les bonnes valeurs. Voici ce jeu, ce que fait chaque header, et la valeur à déployer, avec les correctifs plus profonds liés depuis chaque étape.

Les différents scanners pondèrent les choses différemment. 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 ajoutent leur propre nommage sur les mêmes vérifications. Les headers ci-dessous les couvrent toutes.

Les headers qu'un scanner note

Six headers portent presque toute la note. Posez-les et configurez-les bien, et un A est 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 que la plupart des scanners pondèrent le plus haut, et une CSP stricte sans 'unsafe-inline' est ce qui décroche la meilleure note sur un scanner conscient de 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 la devinez au jugé, alors 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 dit au navigateur de ne jamais joindre votre site autrement qu'en HTTPS, ce qui referme la faille où une première requête part 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 la façon dont certains uploads se transforment en scripts exécutables. Il a une seule valeur et aucun remplaçant moderne, alors 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. Pourquoi l'ancien header est en voie de disparition est traité 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. Un défaut raisonnable garde 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, car c'est celle qui a besoin du cycle report-only, collecter, appliquer pour éviter de casser le trafic réel. C'est aussi le facteur le plus lourd, donc elle mérite le soin supplémentaire.

Si votre note basse vient d'une agence de notation

Les agences de notation de sécurité notent les mêmes headers mais publient leurs propres noms de findings, et le correctif est le même jeu de headers bien configuré. Si votre finding vient de l'une d'elles, les guides par agence relient 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 deux, celles-ci détaillent le compromis :

X-Frame-Options contre frame-ancestors pour le contrôle du framing.
HSTS contre upgrade-insecure-requests pour forcer HTTPS.
no-cache contre no-store pour garder les réponses sensibles hors des caches partagés.
SameSite contre les tokens CSRF pour la défense contre les requêtes cross-site.

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 quels headers sont présents, lesquels manquent, et lesquels portent des valeurs faibles, pour que vous corrigiez en une seule passe éclairée au lieu de deviner. Le scanner de headers de sécurité vous donne cette liste, le scanner CSP rend compte de la politique en particulier, et l'évaluateur CSP note une politique brouillon avant que vous la 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, donc la relever est aussi une checklist : 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.