Subresource Integrity (SRI) : sécuriser vos scripts de CDN

Comment fonctionne SRI

Le principe est un scellé numérique. Vous calculez une empreinte (un hash SHA-384, par exemple) du fichier exact que vous voulez charger, puis vous l'inscrivez dans l'attribut « integrity » de la balise <script> ou <link>. À chaque chargement, le navigateur télécharge la ressource, recalcule son empreinte et la compare à celle déclarée. Si les deux correspondent, il exécute le fichier ; sinon, il le bloque purement et simplement.

Conséquence : même si le CDN est piraté et sert un fichier modifié, l'empreinte ne correspond plus et le code malveillant n'est jamais exécuté chez vos visiteurs. SRI transforme une confiance aveugle envers un tiers en une vérification automatique et infalsifiable, à chaque chargement de page.

Ajouter un attribut integrity

Deux attributs vont de pair : « integrity » (l'empreinte, préfixée par l'algorithme, par exemple sha384-…) et « crossorigin="anonymous" » (indispensable pour que le navigateur puisse lire la ressource tierce afin d'en vérifier le hash). La plupart des CDN sérieux fournissent déjà la valeur SRI toute prête à copier ; sinon, vous pouvez la générer vous-même.

<script src="https://cdn.exemple.com/lib.min.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        crossorigin="anonymous"></script>

<link rel="stylesheet" href="https://cdn.exemple.com/style.css"
      integrity="sha384-…"
      crossorigin="anonymous">

cat lib.min.js | openssl dgst -sha384 -binary | openssl base64 -A

Précautions et limites

SRI verrouille une version EXACTE du fichier : c'est sa force, mais cela signifie que vous devez épingler une URL versionnée (par exemple lib-3.7.1.min.js) et non une URL « latest » qui changerait sous vos pieds — sinon le hash cesserait de correspondre et la ressource serait bloquée. Pensez donc à mettre à jour l'empreinte en même temps que la version, dans le cadre de votre maintenance.

SRI ne s'applique qu'aux ressources <script> et <link> ; il ne protège pas les images ou les requêtes dynamiques. Il se combine idéalement avec une Content-Security-Policy, qui peut même exiger le SRI pour tous les scripts (directive « require-sri-for »). Pour les ressources de votre propre domaine, SRI n'est pas nécessaire : la protection vise les tierces parties.

Vérifier votre couverture

Passez en revue toutes les balises <script> et <link> de vos pages qui pointent vers un domaine autre que le vôtre : chacune devrait porter un attribut « integrity ». CheckCyber compte automatiquement les scripts tiers dépourvus de SRI et les signale. Relancez un audit après avoir ajouté les empreintes pour confirmer que le vecteur « intégrité des scripts tiers » repasse au vert.

Adoptez le réflexe : chaque fois que vous ajoutez une ressource externe, récupérez sa valeur SRI en même temps que son URL. C'est un petit geste au moment de l'intégration qui vous protège durablement d'une compromission côté fournisseur.