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 depuis des articles écrits il y a dix ans. Le résultat, ce sont des jeux de headers qui transportent des directives obsolètes, parfois des directives qui ne font activement 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 qui valent vraiment encore la peine d'être envoyés. Référence complète : headers de sécurité hérités.

Header hérité	Verdict	Remplaçant
`X-Frame-Options`	⚠️ Garder en repli	CSP `frame-ancestors`
`X-XSS-Protection`	❌ Retirer (envoyer `0`)	Une CSP sans `'unsafe-inline'`
`Feature-Policy`	❌ Retirer	`Permissions-Policy`
CSP `report-uri`	⚠️ Garder en repli	CSP `report-to` + `Reporting-Endpoints`
`Expect-CT`	❌ Retirer	Aucun, la Certificate Transparency est appliquée par défaut
`Public-Key-Pins`	❌ Retirer	Aucun, HPKP a été retiré des navigateurs
`X-Content-Type-Options`	✅ Garder	Aucun, toujours d'actualité
`Strict-Transport-Security`	✅ Garder	Aucun, toujours d'actualité

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 entier lorsqu'ils la rencontrent, donc une politique bâtie sur ALLOW-FROM ne protège 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 : il avait des contournements, et les attaquants pouvaient en abuser pour désactiver sélectivement des scripts légitimes, si bien que Chromium l'a retiré entièrement. Le header contrôle désormais une fonctionnalité qui n'existe plus dans les navigateurs modernes. Le conseil courant est d'envoyer explicitement 0 pour s'assurer qu'aucun comportement hérité résiduel 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 est déprécié. Permissions-Policy est son successeur standardisé, avec une syntaxe d'allowlist revue et la capacité 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 pouvait verrouiller un domaine hors de tous les navigateurs pour la durée de vie de l'épinglage. Il a été retiré des navigateurs 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 expédie des octets qu'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 est aussi l'occasion où l'on retire par accident des headers qu'il faudrait 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 changer quoi que ce soit, voyez l'état actuel. Un scan vous dit quels headers hérités un site en ligne envoie encore et quels remplaçants modernes manquent, pour que vous retiriez et remplaciez en une seule passe éclairée plutôt qu'au jugé. Le scanner de headers de sécurité gratuit de CentralCSP vous donne cette liste avant/après face au tableau ci-dessus, et le guide sur comment améliorer votre note de headers de sécurité prend le relais.

Les remplaçants sont aussi la raison pour laquelle un retrait se vérifie au lieu de se 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é et 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é.