Un site chargeait une bibliothèque JavaScript de widget météo directement depuis le CDN de son éditeur, une pratique courante pour éviter d’héberger soi-même chaque dépendance. Le jour où ce CDN a été compromis, le fichier servi à cette URL, restée identique, contenait du code additionnel de minage de cryptomonnaie exécuté silencieusement dans le navigateur de chaque visiteur du site. Aucune modification n’avait eu lieu côté WordPress : le problème venait entièrement du service tiers, invisible depuis l’administration du site.
Subresource Integrity (SRI) est un mécanisme du navigateur, standardisé par le W3C, qui permet précisément de se prémunir contre ce scénario : vérifier que le fichier reçu correspond exactement à celui attendu, avant de l’exécuter, grâce à une empreinte cryptographique calculée à l’avance.
Comment fonctionne Subresource Integrity
Le principe repose sur l’attribut HTML integrity, ajouté à une balise <script> ou <link>, qui contient une empreinte cryptographique (SHA-256, SHA-384 ou SHA-512) du fichier attendu. Lorsque le navigateur télécharge la ressource, il recalcule cette empreinte sur le contenu réellement reçu et compare le résultat à celui déclaré dans l’attribut. Si les deux ne correspondent pas, le navigateur refuse purement et simplement d’exécuter le script, quelle que soit la raison de la divergence.
<script src="https://cdn.exemple.com/widget-meteo.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>L’attribut crossorigin="anonymous" est requis en complément de integrity pour les ressources chargées depuis un domaine différent de celui du site, car la vérification d’intégrité nécessite un accès aux données de la ressource selon les règles de partage de ressources entre origines (CORS), même sans besoin d’authentification.
Ajouter integrity automatiquement via script_loader_tag
WordPress enregistre normalement ses scripts via wp_enqueue_script(), qui ne propose pas nativement de paramètre pour l’attribut integrity. Le filtre script_loader_tag, disponible depuis WordPress 4.1, permet d’intercepter la balise générée avant son affichage et d’y injecter les attributs manquants :
add_filter( 'script_loader_tag', function ( $tag, $handle, $src ) {
$empreintes = array(
'mon-widget-meteo' => 'sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC',
);
if ( ! isset( $empreintes[ $handle ] ) ) {
return $tag;
}
return str_replace(
' src=',
' integrity="' . esc_attr( $empreintes[ $handle ] ) . '" crossorigin="anonymous" src=',
$tag
);
}, 10, 3 );Cette approche fonctionne avec n’importe quel script enregistré via wp_register_script() ou wp_enqueue_script(), en ciblant le handle défini lors de l’enregistrement plutôt que l’URL complète, ce qui rend le code plus lisible et plus facile à maintenir sur plusieurs scripts.
Générer l’empreinte d’un fichier
L’empreinte SRI se calcule facilement en ligne de commande, une fois le fichier téléchargé pour vérification :
curl -s https://cdn.exemple.com/widget-meteo.js | \
openssl dgst -sha384 -binary | \
openssl base64 -ALe résultat, préfixé par sha384-, constitue la valeur à placer dans l’attribut integrity. Cette opération doit être répétée à chaque mise à jour légitime du script tiers, ce qui amène directement à la principale limite de ce mécanisme.
La limite concrète : les CDN qui changent leurs fichiers sans changer d’URL
Subresource Integrity part du principe qu’une URL donnée sert toujours le même contenu, ou qu’une mise à jour légitime s’accompagne d’un changement d’URL (numéro de version dans le chemin). Or de nombreux CDN, notamment ceux qui servent des bibliothèques « toujours à jour » sur une URL fixe sans version explicite, modifient régulièrement le contenu servi à une URL identique. Dans ce cas, l’empreinte SRI calculée hier devient obsolète dès la prochaine mise à jour du CDN, et le script cesse simplement de se charger, cassant potentiellement une fonctionnalité du site sans avertissement clair pour l’équipe.
La bonne pratique consiste donc à ne réserver Subresource Integrity qu’aux ressources chargées depuis des URL versionnées explicitement (un numéro de version dans le chemin du fichier), et à surveiller le bon chargement des scripts protégés après chaque mise à jour prévue du CDN concerné.
Ce que SRI ne remplace pas
- Il ne protège pas contre un CDN compromis dont le contenu initial malveillant serait déjà présent au moment du calcul de l’empreinte par le développeur lui-même.
- Il ne dispense pas d’une politique de sécurité du contenu (Content-Security-Policy) qui limite par ailleurs les domaines autorisés à servir des scripts sur le site.
- Il n’a aucun effet sur les scripts hébergés localement sur votre propre serveur, dont l’intégrité dépend de la sécurité de votre hébergement, pas de ce mécanisme.
Notre règle sur les projets qui chargent des bibliothèques externes : dès qu’une URL est versionnée explicitement (un numéro dans le chemin du fichier), l’attribut integrity est ajouté systématiquement. Pour les URL « toujours à jour » d’un CDN, on préfère héberger la ressource nous-mêmes plutôt que de renoncer à la protection.
En résumé
Subresource Integrity ferme une porte souvent oubliée : la confiance implicite accordée à un service tiers qui sert des scripts exécutés directement dans le navigateur de vos visiteurs. Ajouté via le filtre script_loader_tag pour les ressources chargées depuis une URL stable et versionnée, ce mécanisme coûte peu à mettre en place et referme un vecteur d’attaque réel, quoique moins souvent médiatisé que les vulnérabilités d’extensions classiques.
