Charger une bibliothèque depuis un CDN est pratique, mais cela introduit une dépendance externe. Subresource Integrity (SRI) permet au navigateur de vérifier que le fichier reçu correspond exactement à l’empreinte attendue.
Subresource Integrity (SRI) : vérifier l’intégrité des ressources externes
Comprenez comment SRI utilise une empreinte cryptographique pour vérifier qu’un script ou une feuille de style externe correspond au fichier attendu.
Afficher le sommaire
Le principe
Vous calculez une empreinte cryptographique d’une version précise du fichier et l’ajoutez à l’attribut integrity de la balise concernée. Si le contenu téléchargé ne produit pas la même empreinte, le navigateur refuse de l’utiliser.
Le générateur de hash SRI permet de préparer cette valeur localement.
SRI convient aux ressources stables
Le mécanisme fonctionne bien pour une ressource versionnée et immuable. Si le fournisseur modifie le fichier derrière la même URL, l’empreinte change et la ressource sera bloquée. C’est justement le comportement recherché pour l’intégrité, mais il faut l’intégrer au processus de mise à jour.
crossorigin peut être nécessaire
Pour des ressources provenant d’une autre origine, la configuration CORS et l’attribut crossorigin doivent être compatibles avec le chargement SRI. Il faut donc tester le comportement réel, pas seulement copier une empreinte.
SRI et CSP sont complémentaires
La CSP répond principalement à la question « quelles origines et quels contenus sont autorisés ? ». SRI répond à « ce fichier précis correspond-il à la version attendue ? ». Une origine autorisée peut toujours servir un fichier modifié ; SRI ajoute alors une vérification d’intégrité.
Pour comprendre la différence entre empreinte, chiffrement et comparaison, poursuivez avec le guide Hash et intégrité.
Cet article vous a-t-il été utile ?
Sources et références
- W3C — Subresource Integrity (s’ouvre dans un nouvel onglet)Page en anglais
- MDN — Subresource Integrity (s’ouvre dans un nouvel onglet)Page en anglais