L'intégrité des sous-ressources pour les scripts et feuilles de style tiers

Ce que c'est

MDN (cité) décrit l'intégrité des sous-ressources comme une défense contre un hôte tiers compromis : l'attribut integrity porte un ou plusieurs hachages, chacun préfixé par sha256-, sha384- ou sha512-, et avant d'exécuter un script ou d'appliquer une feuille de style, le navigateur hache le contenu récupéré et le compare. Il n'utilise que l'algorithme le plus fort présent, accepte une correspondance avec n'importe laquelle des valeurs listées pour cet algorithme, et en cas de désaccord refuse la ressource avec une erreur réseau. Cela s'applique à <script> et à <link> avec un rel de stylesheet, preload ou modulepreload. La spécification du W3C (citée) indique que l'intégrité des sous-ressources exige le CORS : une ressource d'origine croisée doit être demandée avec l'attribut crossorigin, et le serveur doit répondre avec Access-Control-Allow-Origin, faute de quoi le contrôle ne peut pas être effectué.

Pourquoi c'est important

Une page qui charge https://cdn.example/lib.js exécute tout ce que cet hôte sert, aujourd'hui et après que l'hôte a été compromis, vendu, ou détourné via le DNS. Un hachage transforme « faire confiance à l'hôte » en « faire confiance à ce fichier précis », ce qui relève de la même discipline que le pinning d'une dépendance par empreinte.

Comment l'appliquer

• Calculer le hachage à partir des octets exacts qui ont été testés : cat lib.js | openssl dgst -sha384 -binary | openssl base64 -A (d'après MDN), ou reprendre la valeur produite par l'empaqueteur.
• Ne pinner que des URL versionnées (/lib@1.2.3/lib.min.js) ; une URL « latest » échouera dès que le fournisseur la mettra à jour, ce qui est le mécanisme qui fonctionne comme prévu.
• Ajouter crossorigin="anonymous" à chaque élément d'origine croisée porteur d'integrity ; sans cela, le navigateur ne chargera pas du tout la ressource.
• Traiter une mise à jour de hachage comme une mise à jour de dépendance : récupérer le nouveau fichier, revoir le diff ou le journal des modifications, recalculer, valider.
• Surveiller l'outil de suivi d'erreurs pour un échec de chargement de la ressource pinnée (un script qui ne définit jamais sa variable globale) ; une vague soudaine signifie que le fournisseur a changé le fichier ou que quelqu'un y a touché.
• Combiner avec une Content Security Policy qui restreint les sources de scripts ; SRI vérifie le contenu, CSP vérifie l'origine.

Pièges

Les ressources qui varient légitimement d'une requête à l'autre (gestionnaires de balises, scripts A/B, paquets personnalisés) ne peuvent pas être pinnées ; il faut soit auto-héberger une copie fixe, soit accepter la confiance accordée. Hacher un fichier minifié après un pipeline qui le re-minifie. Oublier qu'un script chargé à l'exécution par le script pinné n'est pas couvert. Un CDN sans en-têtes CORS, ce qui fait échouer tout chargement pinné.