# Hérités (/fr/docs/web-security/policies/legacy-headers)



Plusieurs anciens headers de sécurité ont été supplantés par des politiques plus
récentes, compatibles avec le reporting. Cette page relie chaque header hérité à son
remplaçant moderne et dit s'il vaut encore la peine d'être envoyé, pour nettoyer un
jeu de headers sans perdre de protection.

## En un coup d'œil [#en-un-coup-dœil]

| Header hérité                                                               | Statut      | Remplaçant moderne                                                                                         | Statut du remplaçant | Encore à envoyer                                               |
| --------------------------------------------------------------------------- | ----------- | ---------------------------------------------------------------------------------------------------------- | -------------------- | -------------------------------------------------------------- |
| [`X-Frame-Options`](/fr/docs/web-security/security-headers/x-frame-options) | ⚠️ Déprécié | CSP [`frame-ancestors`](/fr/docs/web-security/policies/content-security-policy/directives/frame-ancestors) | ✅ Bon                | Pour couvrir les vieux navigateurs ; `ALLOW-FROM` est obsolète |
| `Feature-Policy`                                                            | ⚠️ Déprécié | [Permissions-Policy](/fr/docs/web-security/policies/permissions-policy)                                    | ✅ Bon                | Non                                                            |
| `X-XSS-Protection`                                                          | ⚠️ Déprécié | CSP (bloquer les scripts inline)                                                                           | ✅ Bon                | Non, quasiment mort ; envoyez `0`                              |
| `report-uri` (CSP)                                                          | ⚠️ Déprécié | `report-to` + [Reporting-Endpoints](/fr/docs/web-security/reporting-api/headers/reporting-endpoints)       | ✅ Bon                | Seulement pour les anciennes versions de navigateurs           |

## X-Frame-Options vs frame-ancestors [#x-frame-options-vs-frame-ancestors]

<Callout type="error" title="X-Frame-Options est hérité">
  La valeur `ALLOW-FROM` est obsolète et les navigateurs modernes ignorent le header entier quand ils la voient. Utilisez `frame-ancestors` de CSP.
</Callout>

La directive CSP `frame-ancestors` est le remplaçant de
[`X-Frame-Options`](/fr/docs/web-security/security-headers/x-frame-options) : elle
accepte une liste de sources complète, et un navigateur qui la prend en charge
l'utilise en ignorant le header, donc envoyer les deux est une défense en profondeur
raisonnable pour les vieux clients. Pour la correspondance valeur par valeur et
lequel envoyer, voyez
[X-Frame-Options vs frame-ancestors](/fr/blog/x-frame-options-vs-frame-ancestors).

## Feature-Policy vs Permissions-Policy [#feature-policy-vs-permissions-policy]

<Callout type="error" title="Feature-Policy est déprécié">
  Feature-Policy a été renommé en Permissions-Policy pendant la standardisation et n'est plus développé sous l'ancien nom. Utilisez [Permissions-Policy](/fr/docs/web-security/policies/permissions-policy), qui le remplace avec une syntaxe d'allowlist révisée et ajoute la prise en charge de la Reporting API.
</Callout>

[Feature-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy)
contrôlait l'accès aux fonctionnalités du navigateur mais est déprécié. Migrez ses
directives vers Permissions-Policy, les noms de fonctionnalités sont largement les
mêmes, mais la syntaxe diffère (des allowlists entre parenthèses plutôt que des
listes séparées par des espaces), et Permissions-Policy peut signaler les violations
via la Reporting API.

## X-XSS-Protection vs CSP [#x-xss-protection-vs-csp]

<Callout type="error" title="X-XSS-Protection est quasiment mort">
  Le XSS auditor du navigateur qu'il contrôlait a été retiré des navigateurs parce qu'il pouvait être détourné. Appuyez-vous plutôt sur une CSP solide, et envoyez `X-XSS-Protection: 0` pour désactiver tout comportement hérité résiduel.
</Callout>

Le header activait un auditeur XSS intégré qui avait des contournements et pouvait
être retourné contre des scripts légitimes, donc Chromium l'a retiré. La vraie
protection vient d'une CSP qui bloque les scripts inline : un `script-src` sans
`'unsafe-inline'`, utilisant des
[nonces ou des hashes](/fr/docs/web-security/policies/content-security-policy/values/csp-hashes-nonce),
et Trusted Types.

## report-uri vs report-to et Reporting-Endpoints [#report-uri-vs-report-to-et-reporting-endpoints]

Le câblage du reporting a évolué en trois générations : la directive CSP `report-uri`
(dépréciée), le header
[`Report-To`](/fr/docs/web-security/reporting-api/headers/report-to) (déprécié), et le header
actuel [`Reporting-Endpoints`](/fr/docs/web-security/reporting-api/headers/reporting-endpoints).
La directive `report-to` est désormais multi-navigateurs : Chrome la prend en charge
depuis des années, et Safari et Firefox la prennent désormais en charge aussi. Faites de `report-to`
plus `Reporting-Endpoints` le câblage principal, et gardez `report-uri` seulement
pour couvrir les utilisateurs sur d'anciennes versions de navigateurs, pas des
moteurs entiers. Le header hérité `Report-To` n'est nécessaire que pour
[Network Error Logging](/fr/docs/web-security/policies/network-error-logging) ;
l'histoire complète est dans
[Report-To vs Reporting-Endpoints](/fr/docs/web-security/reporting-api/concepts/report-to-vs-reporting-endpoints).

## Les headers qui ne sont pas supplantés [#les-headers-qui-ne-sont-pas-supplantés]

Tous les vieux headers ne sont pas obsolètes.
[`X-Content-Type-Options: nosniff`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Content-Type-Options)
(empêche le sniffing de type MIME) et
[`Strict-Transport-Security`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security)
(HSTS, impose HTTPS) sont toujours recommandés et n'ont pas de remplaçant basé sur le
reporting, donc gardez-les. Notez que le `upgrade-insecure-requests` de CSP complète
HSTS mais ne le remplace pas ; il met à niveau les requêtes de sous-ressources, pas
la navigation de premier niveau que HSTS protège.

## Voir aussi [#voir-aussi]

* [directive frame-ancestors](/fr/docs/web-security/policies/content-security-policy/directives/frame-ancestors)
* [Permissions-Policy](/fr/docs/web-security/policies/permissions-policy)
* [Report-To vs Reporting-Endpoints](/fr/docs/web-security/reporting-api/concepts/report-to-vs-reporting-endpoints)
* [Les headers de sécurité hérités à retirer](/fr/blog/legacy-security-headers-to-retire)
* Scannez votre jeu de headers avec le [scanner de headers de sécurité](/tools/security-headers).

## Sources [#sources]

* [MDN, X-Frame-Options](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Frame-Options)
* [MDN, CSP frame-ancestors](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/frame-ancestors)
* [MDN, Feature-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy)
* [Chromium, XSS Auditor](https://www.chromium.org/developers/design-documents/xss-auditor/)