# Headers de sécurité hérités que vous pouvez retirer (/fr/blog/legacy-security-headers-to-retire) 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](/fr/docs/web-security/policies/legacy-headers). | 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-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`](/fr/docs/web-security/policies/content-security-policy/directives/frame-ancestors) est le remplaçant moderne, elle gère plusieurs origines, les wildcards et `'none'`. ```http 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](/fr/blog/x-frame-options-vs-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](/fr/blog/frame-ancestors-without-csp-header). ## X-XSS-Protection, abandonnez-le [#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 : ```http X-XSS-Protection: 0 ``` La vraie protection contre le XSS vient d'une CSP qui bloque les scripts inline : voyez [retirer unsafe-inline](/fr/blog/unsafe-inline-csp) et l'usage des nonces, des hashes et des Trusted Types. ## Feature-Policy, remplacez par Permissions-Policy [#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é](/fr/blog/permissions-policy-explained)). Migrez les directives ; les noms de fonctionnalités sont en grande partie les mêmes, la syntaxe ne l'est pas. ```http Permissions-Policy: geolocation=(), camera=(self) ``` ## report-uri, passez à report-to [#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](/fr/blog/report-uri-vs-report-to). ## Expect-CT et Public-Key-Pins, supprimez-les [#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](/fr/docs/web-security/security-headers/deprecated-headers). ## Headers qui ne sont pas hérités, gardez ceux-ci [#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 [#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é](/tools/security-headers) 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é](/fr/blog/improve-security-headers-grade) 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](/fr/docs/web-security/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 [#étapes-suivantes] * Remplacez la protection anti-clickjacking : [frame-ancestors](/fr/docs/web-security/policies/content-security-policy/directives/frame-ancestors). * Remplacez Feature-Policy : [Permissions-Policy](/fr/docs/web-security/policies/permissions-policy). * Construisez la CSP qui remplace X-XSS-Protection : [comment construire une CSP solide](/fr/blog/how-to-build-a-strong-csp). [Scannez vos headers de sécurité](/register). ## Sources [#sources] * [W3C, CSP Level 3 - frame-ancestors](https://www.w3.org/TR/CSP3/#directive-frame-ancestors) * [W3C, Permissions Policy](https://www.w3.org/TR/permissions-policy-1/) * [Chromium, intent to remove the XSS Auditor](https://groups.google.com/a/chromium.org/g/blink-dev/c/TuYw-EZhO9g) * [MDN, X-XSS-Protection](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-XSS-Protection) * [MDN, X-Frame-Options](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Frame-Options) * [MDN, Expect-CT (déprécié)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Expect-CT) * [RFC 7469, Public Key Pinning Extension for HTTP](https://www.rfc-editor.org/rfc/rfc7469) * [OWASP, HTTP headers cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html)