Hérités
Les anciens headers de sécurité comme X-Frame-Options et Feature-Policy, ce qui les a remplacés, et faut-il encore les envoyer.
Dernière mise à jour:
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
| Header hérité | Statut | Remplaçant moderne | Statut du remplaçant | Encore à envoyer |
|---|---|---|---|---|
X-Frame-Options | ⚠️ Déprécié | CSP frame-ancestors | ✅ Bon | Pour couvrir les vieux navigateurs ; ALLOW-FROM est obsolète |
Feature-Policy | ⚠️ Déprécié | 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 | ✅ Bon | Seulement pour les anciennes versions de navigateurs |
X-Frame-Options vs frame-ancestors
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.
La directive CSP frame-ancestors est le remplaçant de
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.
Feature-Policy vs Permissions-Policy
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, qui le remplace avec une syntaxe d'allowlist révisée et ajoute la prise en charge de la Reporting API.
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 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.
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,
et Trusted Types.
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 (déprécié), et le header
actuel 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 ;
l'histoire complète est dans
Report-To vs Reporting-Endpoints.
Les headers qui ne sont pas supplantés
Tous les vieux headers ne sont pas obsolètes.
X-Content-Type-Options: nosniff
(empêche le sniffing de type MIME) et
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
- directive frame-ancestors
- Permissions-Policy
- Report-To vs Reporting-Endpoints
- Les headers de sécurité hérités à retirer
- Scannez votre jeu de headers avec le scanner de headers de sécurité.
Sources
Connection-Allowlist
Connection-Allowlist déclare une allowlist en refus par défaut des destinations autorisées pour une page, et le navigateur bloque toute autre connexion sortante.
Aperçu
Ce que sont les headers de sécurité HTTP, la liste complète avec leur statut, ce contre quoi chacun protège et où chacun est documenté.