SRI

SRI (Subresource Integrity) est une fonctionnalité HTML5 qui vous permet de fixer le hachage SHA-256/SHA-384/SHA-512 d’une ressource externe. Le navigateur calcule le hachage lors du téléchargement et refuse d’exécuter la ressource si les hachages ne correspondent pas.

Exemple : <script src="https://cdn.example/lib.js" integrity="sha384-AbC..." crossorigin="anonymous"></script>

Ce contre quoi cela protège : une compromission du CDN. Si un attaquant prend le contrôle du CDN et sert du JavaScript modifié, chaque site qui inclut le script via SRI refusera d’exécuter la version modifiée. Sans SRI, chaque site reçoit silencieusement le payload malveillant.

Le compromis : fixer un hachage signifie que vous ne pouvez pas mettre à jour la ressource sans mettre à jour chaque page qui y fait référence. Pour les ressources de première partie que vous construisez de toute façon, SRI est une défense à faible coût. Pour les scripts CDN tiers (jQuery, balises d’analyse), c’est un gain de sécurité significatif au prix d’une propagation des mises à jour plus lente.

SRI nécessite crossorigin="anonymous" sur la balise ainsi qu’un en-tête CORS sur la réponse CDN — le navigateur doit pouvoir lire la réponse de manière opaque.

Incidents réels que SRI aurait arrêtés : la famille d’attaques Magecart de vol de cartes a compromis à plusieurs reprises du JavaScript tiers hébergé par des fournisseurs de confiance (BrowserAloud, Inbenta, Picreel) et injecté un code voleur de cartes qui se chargeait dans des milliers de pages de paiement e-commerce. La violation de Ticketmaster en 2018 et celle de British Airways en 2018 impliquaient toutes deux des attaquants modifiant des scripts sur des hôtes que les sites affectés incluaient via <script src="…">. SRI est l’atténuation spécifique : si ces sites avaient fixé le hachage d’intégrité de la version du script qu’ils voulaient charger, le payload modifié aurait échoué à la vérification et le navigateur aurait refusé de l’exécuter.

Comment générer et faire tourner les hachages SRI en pratique : pour les fichiers que vous possédez, le pipeline de construction devrait émettre des hachages SRI aux côtés du bundle d’actifs et les intégrer dans le HTML au moment du template (Next.js, Vite et Webpack prennent en charge cela avec des plugins). Pour les bibliothèques tierces, le flux de travail recommandé consiste à verrouiller une version spécifique, copier le fichier sur votre propre CDN et fixer le SRI — compter sur le CDN en amont pour garder les mêmes octets disponibles à la même URL est risqué sur des mois. L’attribut integrity accepte plusieurs hachages séparés par des espaces, permettant les transitions d’algorithme de hachage. Liens connexes : CSP, SHA-256. Référence : W3C — Subresource Integrity.

Exemple concret

Vous souhaitez inclure jQuery 3.7.1 depuis un CDN avec protection SRI. Calculez le hachage SHA-384 du fichier : openssl dgst -sha384 -binary jquery-3.7.1.min.js | openssl base64 -A produit quelque chose comme Bu3qSpvxnAdMaOTsigCcfqUyJYvP7AbsxRRpzqj7M1V2OuoP1bb98c8MQYIPHzxc. Intégrez-le : <script src="https://code.jquery.com/jquery-3.7.1.min.js" integrity="sha384-Bu3qSpvxnAdMaOTsigCcfqUyJYvP7AbsxRRpzqj7M1V2OuoP1bb98c8MQYIPHzxc" crossorigin="anonymous"></script>. Au chargement de la page, le navigateur récupère le fichier, calcule son SHA-384, l’encode en base64 et le compare à l’attribut integrity. Si le CDN sert un fichier falsifié — même un changement d’un seul octet — les hachages divergent, le navigateur bloque l’exécution et une SecurityError apparaît dans DevTools.

Quand et pourquoi cela est important

Chaque fois que votre site charge du JavaScript depuis un domaine que vous ne contrôlez pas, vous faites confiance aux opérateurs de ce domaine, à leur fournisseur CDN, à leur DNS et à chaque étape de TLS entre les deux. Cette confiance est empiriquement mal placée assez souvent pour être importante : les compromissions de la chaîne d’approvisionnement affectant les paquets npm, les plugins jQuery, les conteneurs GTM et les scripts d’analyse ont touché des sites majeurs à un rythme de plusieurs par an. SRI est la défense qui ne nécessite pas de faire confiance à la tierce partie. Combinez avec CSP require-sri-for script ou script-src avec des hachages autorisés explicites pour une défense en profondeur. Référence : MDN — Subresource Integrity.