Vérificateur de SRI

Comment fonctionne cette vérification

Scanaris parcourt le HTML de ta page principale et s'intéresse à deux types de balise : <script src="..."> et <link rel="stylesheet" href="...">. Il résout chaque URL par rapport à celle de la page et la considère externe si son origine (schéma, domaine et port) diffère de la tienne ; cela inclut les URL commençant par //, qui chargent depuis le CDN avec le protocole de la page. Il ignore data: et blob:. Pour chaque ressource externe, il vérifie la présence de l'attribut integrity ; s'il manque, il la note. S'il y en a au moins une, il ouvre un constat de sévérité faible avec le nombre de ressources et les dix premières URL. Les scripts et styles de ton propre domaine ne sont pas signalés : le SRI n'y apporte rien.

Pourquoi c'est important

Quand tu charges une bibliothèque depuis un CDN, tu exécutes dans le navigateur de tes utilisateurs ce que ce CDN décide de servir. Si le CDN est compromis, ou si son domaine change de mains, le fichier peut être remplacé par un autre qui fait la même chose et en plus vole les formulaires ou redirige vers des arnaques. C'est arrivé en juin 2024 avec polyfill.io : le domaine a été vendu, le script s'est mis à injecter du code malveillant et plus de cent mille sites qui l'incluaient l'ont servi sans s'en apercevoir. L'attribut integrity contient le hash du fichier que tu as vérifié ; le navigateur calcule le hash de ce qu'il télécharge et, s'il ne correspond pas, refuse de l'exécuter. C'est de sévérité faible parce qu'il faut d'abord que le CDN soit attaqué, mais quand ça arrive, les dégâts sont totaux et silencieux.

Comment corriger

Option 1 : ajouter integrity aux balises

<script src="https://cdn.jsdelivr.net/npm/chart.js@4.4.0/dist/chart.umd.min.js"
  integrity="sha384-..." crossorigin="anonymous"></script>

Le hash s'obtient en téléchargeant le fichier exact et en lançant :

curl -s https://cdn.jsdelivr.net/npm/chart.js@4.4.0/dist/chart.umd.min.js | openssl dgst -sha384 -binary | openssl base64 -A

cdnjs et jsDelivr affichent le hash prêt à copier à côté de chaque fichier. L'attribut crossorigin="anonymous" est obligatoire pour que le navigateur puisse vérifier une ressource d'une autre origine. Et l'URL doit pointer vers une version figée (@4.4.0), jamais vers latest : si le CDN met à jour le fichier, le hash ne correspond plus et ton site cesse de charger cette bibliothèque, ce qui est exactement ce que tu veux face à un changement non vérifié.

Option 2 : servir les bibliothèques depuis ton domaine

Installe-les avec npm et laisse ton bundler (Vite, webpack, Nuxt, Next.js) les inclure dans ton build. Le fichier sort alors de ton serveur, avec un hash dans son nom, et le SRI n'est plus nécessaire. C'est l'option habituelle des projets modernes et celle qui règle le constat à la racine.

Ce qui n'accepte pas le SRI

Les feuilles de style de Google Fonts changent selon le navigateur qui les demande, donc leur hash n'est pas stable : soit tu acceptes ce constat, soit tu héberges les polices toi-même (ce qui améliore aussi la confidentialité et la vitesse). Les scripts d'analyse et de publicité qui se mettent à jour seuls (gtag.js, le pixel Meta) n'acceptent pas non plus un hash fixe ; là, la défense est la CSP, qui limite ce que chaque origine peut faire et que mesure CSP faible.

Vérifie que c'est corrigé

curl -s https://tondomaine.com | grep -oE '<(script|link)[^>]*(src|href)="(https?:)?//[^"]+"[^>]*>' | grep -v integrity

Chaque ligne qui sort est une ressource externe sans integrity. S'il ne reste que celles qui ne peuvent pas en avoir (polices, analyse), c'est terminé.

Questions fréquentes

Le SRI ralentit-il le chargement ?

Pas de manière perceptible : calculer un hash SHA-384 d'un fichier de quelques centaines de kilooctets prend des millisecondes. Ce qu'il fait, c'est t'obliger à figer les versions, ce qui est une bonne pratique de toute façon.

Si je mets à jour la bibliothèque, dois-je changer le hash ?

Oui, et c'est tout l'intérêt : la mise à jour passe par tes mains. Si tu utilises npm et ton bundler, le processus est le même que d'habitude et le build gère le hash.

Et les vieilles versions des bibliothèques du CDN ?

Le SRI garantit que le fichier est celui que tu as choisi, pas qu'il est sûr. Un jQuery 1.12 avec le bon hash a toujours ses failles ; c'est bibliothèques obsolètes qui le détecte.