Headers de sécurité hérités que vous pouvez retirer

Les scanners de sécurité et les agences de notation signalent encore d'anciens headers de réponse, et les équipes les recopient encore d'articles écrits il y a dix ans. Résultat : des jeux de headers qui traînent des directives obsolètes, parfois des directives qui ne font plus rien ou qu'une politique plus récente couvre déjà. Voici un audit court : quels headers hérités retirer, ce qui remplace chacun, et les rares anciens qu'il vaut encore la peine d'envoyer. Référence complète : headers de sécurité hérités.

La suite de cet article reprend chaque ligne dans l'ordre.

X-Frame-Options, remplacez par frame-ancestors

X-Frame-Options était le contrôle anti-clickjacking d'origine : il indiquait qui pouvait placer votre page dans une frame. Il a mal vieilli. La valeur ALLOW-FROM est obsolète, et les navigateurs modernes ignorent le header en entier dès qu'ils la rencontrent : une politique bâtie sur ALLOW-FROM ne protège donc personne. La directive CSP frame-ancestors est le remplaçant moderne, elle gère plusieurs origines, les wildcards et 'none'.

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

Lorsque les deux sont présents, un navigateur compatible utilise frame-ancestors et ignore X-Frame-Options, donc vous pouvez garder X-Frame-Options: DENY ou SAMEORIGIN comme repli pour les navigateurs très anciens. Mais c'est frame-ancestors qui fait le travail aujourd'hui, et X-Frame-Options contre frame-ancestors les compare côte à côte. Si vous ne pouvez pas du tout poser de headers de réponse CSP, voyez la protection anti-clickjacking quand vous ne pouvez pas poser de header CSP.

X-XSS-Protection, abandonnez-le

X-XSS-Protection activait l'auditeur XSS intégré du navigateur. Cet auditeur s'est avéré pire que rien : on savait le contourner, et les attaquants pouvaient en abuser pour désactiver au cas par cas des scripts légitimes, si bien que Chromium l'a retiré complètement. Le header contrôle désormais une fonctionnalité qui n'existe plus dans les navigateurs modernes. L'usage est d'envoyer explicitement 0, pour qu'aucun reste de comportement hérité ne se déclenche :

X-XSS-Protection: 0

La vraie protection contre le XSS vient d'une CSP qui bloque les scripts inline : voyez retirer unsafe-inline et l'usage des nonces, des hashes et des Trusted Types.

Feature-Policy, remplacez par Permissions-Policy

Feature-Policy contrôlait l'accès aux fonctionnalités du navigateur (caméra, géolocalisation, etc.), mais il est déprécié. Permissions-Policy est son successeur standardisé, avec une syntaxe d'allowlist revue et la possibilité de signaler les violations via la Reporting API (Permissions-Policy expliqué). Migrez les directives ; les noms de fonctionnalités sont en grande partie les mêmes, la syntaxe ne l'est pas.

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

report-uri, passez à report-to

La directive CSP report-uri fonctionne encore mais est dépréciée au profit de la directive report-to associée au header Reporting-Endpoints. Comme les navigateurs qui prennent en charge report-to ignorent report-uri, vous pouvez envoyer les deux pendant la transition sans double reporting. La migration complète est dans report-uri vs report-to.

Expect-CT et Public-Key-Pins, supprimez-les

Deux headers ne sont pas tant dépréciés que disparus. Public-Key-Pins (HPKP) permettait à un site d'épingler les certificats que les navigateurs accepteraient pour lui, et une seule erreur suffisait à rendre un domaine inaccessible dans tous les navigateurs pendant toute la durée de l'épinglage. Les navigateurs l'ont retiré plutôt que corrigé. Expect-CT demandait l'application de la Certificate Transparency, que les navigateurs appliquent désormais par défaut : le header n'a donc plus rien à demander.

Aucun des deux n'a de remplaçant, parce qu'aucun n'en a besoin. Supprimez-les ; tout ce qui les envoie encore ajoute des octets que plus aucun navigateur ne lit. Les deux sont traités dans la référence des headers dépréciés.

Headers qui ne sont pas hérités, gardez ceux-ci

Un nettoyage, c'est aussi l'occasion de retirer par accident des headers qu'il faut garder. Deux headers plus anciens ne sont pas obsolètes et n'ont pas de remplaçant fondé sur le reporting : X-Content-Type-Options: nosniff, qui empêche le MIME-type sniffing, et Strict-Transport-Security (HSTS), qui impose HTTPS. Les deux restent recommandés. Ne les retirez pas en supprimant les autres.

Trouvez ce que votre site envoie réellement

Avant de toucher à quoi que ce soit, faites l'état des lieux. Un scan vous dit quels headers hérités un site en ligne envoie encore et quels remplaçants modernes lui manquent : vous retirez et remplacez en une seule passe, en connaissance de cause plutôt qu'au jugé. Le scanner de headers de sécurité gratuit de CentralCSP vous donne cette liste avant/après à confronter au tableau ci-dessus, et le guide pour améliorer votre note de headers de sécurité prend le relais.

Les remplaçants ont un autre avantage : ils permettent de vérifier un retrait au lieu de le supposer. frame-ancestors, Permissions-Policy et report-to signalent tous leurs violations via la Reporting API, ce que les anciens headers ne faisaient jamais. Pointez-les vers un endpoint CentralCSP avant de supprimer le header hérité : vous verrez le contrôle moderne fonctionner sur du trafic réel d'abord.

Étapes suivantes

• Remplacez la protection anti-clickjacking : frame-ancestors.
• Remplacez Feature-Policy : Permissions-Policy.
• Construisez la CSP qui remplace X-XSS-Protection : comment construire une CSP solide.

Scannez vos headers de sécurité.

Sources

• W3C, CSP Level 3 - frame-ancestors
• W3C, Permissions Policy
• Chromium, intent to remove the XSS Auditor
• MDN, X-XSS-Protection
• MDN, X-Frame-Options
• MDN, Expect-CT (déprécié)
• RFC 7469, Public Key Pinning Extension for HTTP
• OWASP, HTTP headers cheat sheet