Date de publication : 17 novembre 2025
À partir de Chrome 141, vous pouvez participer à la phase d'évaluation pour tester les nouvelles fonctionnalités de la stratégie de sécurité du contenu (CSP) que Chrome introduit. Ces fonctionnalités aident les sites Web à se protéger contre les attaques XSS en autorisant plus facilement les sources connues de JavaScript. L'ajout à la liste d'autorisation du code JavaScript connu et le blocage de toutes les autres sources constituent un moyen efficace d'empêcher les attaques XSS. Le code JavaScript injecté par le pirate informatique ne figurera pas sur la liste d'autorisation et sera donc bloqué.
Sans ces fonctionnalités, il est difficile d'avoir une CSP "stricte" qui autorise toutes les sources JavaScript sans avoir de mécanisme de communication de nonce entre l'hôte de script et le site, ou sans connaître à l'avance le hachage complet du script. Ces deux méthodes sont difficiles à déployer si le script change fréquemment et est hébergé par un tiers de confiance, mais distinct. De plus, si un script doit utiliser eval, CSP exige actuellement que vous l'autorisiez pour tous les scripts, ce qui le rend beaucoup plus faible.
Nous essayons de combler cette lacune en fournissant un mécanisme plus efficace pour la liste d'autorisation des scripts basés sur les URL dans script-src, ainsi qu'un mécanisme pour la liste d'autorisation des appels à eval. Vous pourrez utiliser le mécanisme de hachage existant dans script-src pour autoriser les URL de scripts spécifiques et le code JavaScript transmis à eval (et à d'autres fonctions de type eval). Bien que la liste d'autorisation basée sur les URL ne soit peut-être pas aussi stricte qu'une CSP basée sur l'intégrité, ce mécanisme devrait constituer une grande amélioration par rapport à la liste d'autorisation des noms d'hôte existante.
Nous pensons que cela permet de déployer plus facilement une stratégie CSP qui atténue toujours efficacement les attaques XSS en bloquant les scripts inline et eval non autorisés. Ces nouvelles fonctionnalités sont soigneusement conçues et implémentées pour permettre aux sites de définir une règle qui offre une meilleure sécurité dans les navigateurs compatibles avec la nouvelle fonctionnalité, sans provoquer de dysfonctionnement ni de régression de la sécurité dans les navigateurs qui ne le sont pas, sans avoir à effectuer de reniflage de l'agent utilisateur.
Cas d'utilisation
Ajouter des URL spécifiques à la liste d'autorisation pour les utiliser avec script-src
Les sites qui souhaitent autoriser des scripts spécifiques à utiliser avec script-src ont actuellement deux options : autoriser le contenu des scripts via l'intégrité des sous-ressources (SRI) ou utiliser host-source pour autoriser les noms d'hôte. L'intégrité des sous-ressources n'est souvent pas pratique pour les scripts qui changent souvent (par exemple, les scripts d'analyse). La spécification de host-source sera ignorée lorsque strict-dynamic est également défini. De plus, il ne s'agit pas d'une protection complète, car elle n'inclut pas les paramètres d'URL. Cette modification permettra d'ajouter des scripts à la liste d'autorisation à l'aide d'un hachage de leur URL (complète), en prenant en charge à la fois les scripts dynamiques et les configurations qui utilisent strict-dynamic.
Autoriser des scripts spécifiques à utiliser avec des fonctions eval ou similaires
Certains sites nécessitent l'utilisation de fonctions eval ou similaires (transmission de code sous forme de littéraux de chaîne dans setTimeout, setInterval et setImmediate). Pour ces sites, la seule option CSP disponible est unsafe-eval, qui active tous les appels à eval. Nous ajoutons un mécanisme permettant d'ajouter des entrées spécifiques à la liste d'autorisation pour l'évaluation. Ce nouveau mécanisme permet d'autoriser de manière précise les scripts spécifiques nécessaires en hachant directement le contenu du script, au lieu d'être obligé de fournir une CSP unsafe-eval trop large.
Premiers pas
Pour tester la compatibilité avec le hachage de script et d'eval, participez à la
phase d'évaluation des hachages d'URL et d'eval dans CSP script-src, qui se déroule de Chrome 141 à 144.
Ajouter des hachages à script-src
Les URL sont ajoutées à la liste d'autorisation en ajoutant une valeur à la directive script-src CSP sous la forme url-<hash-algorithm>-<script-url-hash>. Cela permettra à tout contenu diffusé par cette URL, quel qu'il soit, de s'exécuter. Le hachage ne doit inclure que l'URL initiale (l'URL incluse sur la page), et non les URL vers lesquelles elle redirige. Les URL absolues et relatives sont acceptées.
Par exemple, l'en-tête CSP suivant autorisera le script diffusé sur https://example.com/example.js :
Content-Security-Policy: script-src 'sha256-u2cYltM/2wbvoRR0jMZ57KmFdVqqdPYa6GtdykFwBGc=';
où 'sha256-u2cYltM/2wbvoRR0jMZ57KmFdVqqdPYa6GtdykFwBGc=' est le hachage sha256 de https://example.com/example.js.
Les scripts évalués via eval ou new Function peuvent être ajoutés à la liste d'autorisation en incluant eval-<hash-algorithm>-<script-contents-hash> dans le script src. Par exemple, l'en-tête CSP suivant autorisera la transmission de la chaîne alert("hello world") à eval() :
Content-Security-Policy: script-src 'eval-sha256-4vpsisrBP00v+tF/SsQ3RXWWYF28JSvTpR9D/wrxn/0=';
où 'eval-sha256-4vpsisrBP00v+tF/SsQ3RXWWYF28JSvTpR9D/wrxn/0=' est le hachage sha256 de alert("hello world").
Pour faciliter l'adoption, lorsqu'un site participe à l'Origin Trial, les hachages des URL et de eval sont imprimés dans la console DevTools et inclus dans les rapports CSP. Cela signifie qu'une règle report-only stricte peut être utilisée pour énumérer tous les hachages nécessaires à la liste d'autorisation.
Maintenir la rétrocompatibilité
Pour autoriser le déploiement de ces règles avant que tous les navigateurs n'aient ajouté la prise en charge, les hachages d'URL peuvent être listés après les listes d'autorisation basées sur l'hôte. Les navigateurs qui comprennent les nouveaux types de hachage ignoreront les listes d'autorisation basées sur l'hôte qui les précèdent, tandis que les navigateurs qui ne les comprennent pas continueront d'appliquer la liste d'autorisation basée sur l'hôte. Les sites peuvent donc définir les deux, en utilisant la règle la plus stricte dans les navigateurs qui la prennent en charge, sans risquer de provoquer des dysfonctionnements dans les navigateurs qui ne la prennent pas en charge, comme le montre l'exemple suivant.
Content-Security-Policy: script-src 'https:' 'url-sha256-u2cYltM/2wbvoRR0jMZ57KmFdVqqdPYa6GtdykFwBGc='
Nous avons également introduit strict-dynamic-url, un équivalent de strict-dynamic qui ne s'applique que lorsque des hachages d'URL sont définis. Étant donné que strict-dynamic entraîne l'ignorance des listes d'autorisation basées sur l'hôte, un site qui souhaite autoriser un hachage spécifique et appliquer strict-dynamic peut utiliser une règle comme celle-ci :
Content-Security-Policy: https: 'strict-dynamic-url' 'url-sha256-u2cYltM/2wbvoRR0jMZ57KmFdVqqdPYa6GtdykFwBGc='
Dans cet exemple, les navigateurs qui ne sont pas encore compatibles avec les hachages n'appliqueront que https:. De même, unsafe-eval sera ignoré par les navigateurs compatibles lorsque des hachages d'évaluation sont présents. Par exemple, la règle suivante sera évaluée comme unsafe-eval. Cela permet d'utiliser eval() sur les navigateurs qui ne sont pas encore compatibles avec les hachages eval, tout en n'autorisant que le eval() de alert("hello world") parmi les navigateurs compatibles avec les hachages eval.
Content-Security-Policy: script-src "unsafe-eval" "'eval-sha256-4vpsisrBP00v+tF/SsQ3RXWWYF28JSvTpR9D/wrxn/0='"
Envoyer des commentaires
Nous aimerions recueillir l'avis des développeurs sur ces extensions afin de script-src. Publiez vos commentaires en tant que problème sur la page d'explication sur GitHub.