Subresource Integrity (SRI)
Vérifier qu’un script ou une feuille de style externe n’a pas été modifié avant de l’utiliser.
Comprendre Subresource Integrity
Un site web ne charge pas toujours tous ses fichiers depuis son propre serveur. Il peut utiliser des scripts JavaScript ou des feuilles de style provenant d’un CDN ou d’un service externe.
Cela signifie que le site fait confiance au fichier fourni par ce service. Si ce fichier est modifié, compromis ou remplacé, le navigateur pourrait normalement charger la nouvelle version sans savoir qu’elle est différente de celle prévue.
Subresource Integrity, souvent abrégé en SRI, permet au site d’indiquer au navigateur l’empreinte exacte du fichier attendu.
Le navigateur peut alors vérifier le fichier avant de l’utiliser. Si son contenu ne correspond plus à l’empreinte attendue, la ressource est refusée.
Configurer SRI
Exemple avec un script JavaScript
Un script externe peut par exemple être chargé ainsi :
<script
src="https://cdn.example.com/library.min.js"
integrity="sha384-..."
crossorigin="anonymous">
</script>
L’attribut
integrity
contient une empreinte cryptographique
correspondant au contenu attendu du fichier.
Lorsque le navigateur télécharge le script, il calcule lui-même l’empreinte du fichier reçu et la compare à celle indiquée dans la page.
- si les deux correspondent, le fichier peut être utilisé ;
- si elles sont différentes, le navigateur refuse la ressource.
Exemple avec une feuille de style
<link
rel="stylesheet"
href="https://cdn.example.com/style.css"
integrity="sha384-..."
crossorigin="anonymous">
Les algorithmes utilisés
L’empreinte est généralement calculée avec une fonction cryptographique telle que :
sha256
Produit une empreinte SHA-256 du fichier.
sha384
Produit une empreinte SHA-384. Cette forme est fréquemment rencontrée avec les ressources distribuées par des CDN.
sha512
Produit une empreinte SHA-512.
Pourquoi vérifier l’intégrité des ressources ?
Un script JavaScript chargé par une page peut disposer de possibilités importantes dans le navigateur de l’utilisateur.
Si un service externe, un CDN ou une ressource distribuée est compromis, un attaquant pourrait tenter de remplacer un fichier légitime par une version malveillante.
Le site continuerait alors à demander le fichier à la même adresse, mais son contenu pourrait être différent.
Un script ainsi modifié pourrait notamment tenter de :
- récupérer des informations accessibles depuis la page ;
- effectuer des actions avec les droits de l’utilisateur ;
- modifier le contenu affiché ;
- rediriger l’utilisateur ou lui présenter une interface trompeuse ;
- communiquer certaines informations à un service contrôlé par un attaquant.
Avec SRI, même si le fichier disponible à l’adresse externe a été remplacé, son empreinte ne correspond plus à celle enregistrée dans le site.
Le navigateur peut alors bloquer la ressource avant son exécution, ce qui évite de faire automatiquement confiance à un fichier simplement parce qu’il provient de l’adresse attendue.
Bonnes pratiques et limites
Bonnes pratiques
- Utiliser SRI pour les scripts et feuilles de style externes dont le contenu doit rester identique.
- Vérifier que l’empreinte utilisée correspond exactement au fichier réellement chargé.
- Mettre à jour l’empreinte lorsqu’une ressource externe est volontairement mise à jour.
- Éviter de charger inutilement des scripts provenant de nombreux services tiers.
- Utiliser SRI en complément des autres protections, notamment d’une Content-Security-Policy correctement configurée.
Une modification légitime bloque également le fichier
SRI ne cherche pas à déterminer si une modification est bonne ou mauvaise. Il vérifie uniquement si le fichier reçu est exactement celui qui était attendu.
Si le fournisseur met volontairement
une bibliothèque à jour,
l’empreinte du fichier change.
Il faut alors mettre à jour
la valeur
integrity
utilisée par le site.
Ce que SRI ne remplace pas
SRI constitue une protection importante contre la modification inattendue de ressources externes, mais il ne sécurise pas l’ensemble du site à lui seul.
Il ne remplace notamment pas :
- une Content-Security-Policy correctement configurée ;
- la sécurité du code JavaScript lui-même ;
- la mise à jour des dépendances ;
- HTTPS ;
- la maîtrise des services tiers auxquels le site fait confiance.
Lorsqu’un site dépend de fichiers externes dont le contenu doit rester stable, SRI permet donc d’ajouter une vérification supplémentaire avant que le navigateur ne leur fasse confiance.