Audit des scripts tiers et SRI
Chaque script tiers que votre page charge s’exécute avec tous les privilèges de votre page : il peut lire le DOM, observer les saisies de formulaire et agir dans les sessions de vos visiteurs. Cet audit récupère le HTML statique d’une page, liste chaque script externe auquel elle fait référence, marque lesquels sont tiers, lesquels portent un hash Subresource Integrity (SRI) et lesquels sont épinglés à une version exacte — et, pour les scripts tiers sans intégrité, il calcule le hash sha384 pour que vous puissiez le coller directement dans la balise.
Dernière mise à jour:
Vous craignez qu’un script fournisseur sur votre site change ou tombe ? Surveillez-le gratuitement avec myeventwatch — alertes d’expiration et d’indisponibilité, sans carte.
Ce que cet audit vérifie — et ce qu’il ne peut pas voir
Le vérificateur récupère la page une fois et analyse le HTML qui lui est servi — le HTML statique uniquement. Chaque <script src> de ce balisage est listé avec son hôte, classé comme interne lorsque l’hôte correspond au domaine enregistrable de votre page et comme tiers dans le cas contraire, et contrôlé sur les deux attributs qui décident si le navigateur peut vous protéger : integrity, le hash SRI que le navigateur vérifie avant d’exécuter le fichier, et crossorigin, dont un contrôle SRI inter-origines a besoin pour fonctionner. La version dans l’URL est aussi évaluée : un script adressé comme [email protected] ou /v2.4/ est épinglé, tandis qu’une adresse latest ou sans version est une cible mouvante dont le contenu peut changer à tout moment sans que personne touche à votre site.
Soyez clair sur la frontière, car elle compte : la v1 n’analyse que le HTML statique de la page — les scripts injectés à l’exécution par JavaScript ne sont pas couverts. Les gestionnaires de balises, les outils de consentement et les widgets de discussion créent couramment des éléments script depuis du code après le chargement de la page, et une analyse statique ne les voit jamais. Traitez cet audit comme l’inventaire de ce à quoi vos gabarits et votre CMS font directement référence — en général la partie la plus grande et la plus réparable du problème — et auditez les conteneurs du gestionnaire de balises séparément, dans son propre aperçu et son historique de modifications. Les scripts en ligne (les blocs sans src) sont comptés comme un fait dans le résultat, car ils ne peuvent porter aucun SRI ; le guide associé explique quoi en faire.
La colonne du hash : calculé, jamais deviné
Pour les scripts tiers dépourvus de l’attribut integrity, le vérificateur récupère le script lui-même — par le même chemin de récupération protégé contre les SSRF que tous les autres vérificateurs de ce site, plafonné aux 15 premiers scripts de ce type et à 512 Ko chacun — et calcule son hash SHA-384. Lorsque la récupération réussit, la cellule SRI affiche l’extrait complet, integrity="sha384-…", prêt à coller dans votre balise à côté de crossorigin="anonymous". Un hash n’est affiché que lorsque le script a réellement été récupéré. Si la récupération a échoué, si le fichier était trop gros ou si le script se trouvait au-delà du plafond de 15, la cellule affiche cette note à la place — jamais un marqueur ni une valeur devinée — et la correction consiste à générer le hash dans votre propre chaîne de construction, où le fichier exact est sous la main.
Vérifications voisines : le contrôle des en-têtes de sécurité note les en-têtes de réponse — y compris la Content-Security-Policy, la partenaire naturelle de SRI —, le évaluateur SSL couvre le transport par lequel ces scripts arrivent, et l’article associé les scripts tiers sont un risque de chaîne d’approvisionnement parcourt un incident réel, ce que SRI arrête et ce qu’il n’arrête pas, et une routine d’audit reproductible.
Comment lire les verdicts : un script tiers avec intégrité et version épinglée est le cas sain — le navigateur refusera un fichier échangé ou modifié. Un script tiers sans intégrité n’est pas automatiquement malveillant ; il est sans protection, ce qui signifie que son contenu est ce que son hôte sert aujourd’hui, et que votre seul avertissement d’un changement serait le dommage lui-même. Les adresses non épinglées méritent la même suspicion que les hashes absents, car un hash SRI sur une URL latest se brise dès la première mise à jour du fournisseur — c’est pourquoi les deux constats sont rapportés côte à côte, et pourquoi la correction durable est toujours la paire : épinglez la version exacte, puis calculez le hash de ce fichier exact.
Les faits que cette page affiche
| Tiers | Un script dont le domaine enregistrable de l’hôte diffère de celui de la page : du code servi par quelqu’un d’autre, s’exécutant avec les privilèges de votre page. |
| Intégrité (SRI) | Si la balise porte un attribut integrity : un hash cryptographique que le navigateur vérifie avant d’exécuter le fichier, en le refusant à la moindre différence. |
| Crossorigin | Si la balise porte l’attribut crossorigin qu’un contrôle SRI inter-origines requiert ; sans lui, les navigateurs ne peuvent pas appliquer SRI au chargement. |
| Épinglé | Si l’URL nomme une version exacte ([email protected], /v2.4/) plutôt qu’une adresse latest flottante ou sans version dont le contenu peut changer en silence. |
| SRI calculé | Pour les scripts tiers sans intégrité, le hash sha384 que le vérificateur a calculé en récupérant réellement le fichier — affiché uniquement après une récupération réussie, pour les 15 premiers scripts de ce type. |
Questions fréquentes
Cet audit voit-il tous les scripts que ma page exécute ?
Non — et la page le dit clairement : la v1 n’analyse que le HTML statique de la page, donc les scripts injectés à l’exécution par JavaScript ne sont pas couverts. Les gestionnaires de balises, les outils de test A/B, les bandeaux de consentement et les widgets de discussion injectent couramment des scripts après le chargement ; auditez-les dans le gestionnaire de balises ou avec le panneau réseau d’un navigateur. Ce que cet audit couvre entièrement, c’est chaque script auquel votre HTML servi fait directement référence — là où vivent les bibliothèques, les widgets de CDN et les codes de surveillance.
D’où vient le hash dans la colonne SRI ?
Le vérificateur récupère le fichier du script lui-même et calcule son hash SHA-384, pour les scripts tiers sans attribut integrity : les 15 premiers, jusqu’à 512 Ko chacun. Un hash n’est affiché que lorsque le script a réellement été récupéré : si la récupération a échoué, si le fichier était trop gros ou si le plafond a été atteint, la cellule affiche cette note à la place d’un hash. Collez l’extrait dans votre balise script avec crossorigin="anonymous" et relancez l’audit après tout changement de version : une nouvelle version signifie un nouveau hash.
Le script de mon gestionnaire de balises ne peut pas avoir de hash fixe. Et alors ?
Exact — un conteneur de gestionnaire de balises est conçu pour changer, donc SRI ne peut pas l’épingler, et il en va de même pour tout script dont le but entier est de charger du code changeant. Pour ceux-là, les contrôles sont différents : restreignez qui peut publier dans le conteneur, passez son historique de modifications en revue comme des changements de code, chargez-le uniquement sur les pages qui en ont besoin, et utilisez une Content-Security-Policy pour limiter ce que les scripts injectés peuvent faire et où ils peuvent envoyer des données. SRI protège les bibliothèques fixes ; la gouvernance protège les dynamiques.
Un attribut integrity manquant est-il une urgence ?
C’est une exposition permanente, pas un incident. Le script est presque sûrement le fichier que le fournisseur entend servir aujourd’hui ; le problème est que rien n’arrêterait ni ne signalerait un fichier différent demain — après une compromission du fournisseur, un compte détourné ou un domaine expiré. Ordre de correction : d’abord les scripts des pages avec connexions, paiements ou données personnelles, puis les bibliothèques épinglées et hashées partout ailleurs, puis la longue traîne. Chaque correction est un changement d’une ligne dans la balise une fois la version épinglée.
Pourquoi la colonne d’épinglage appelle-t-elle un script « latest » ou « sans version » ?
Le verdict d’épinglage est une lecture heuristique de l’URL : un segment ressemblant à une version, comme @1.2.3 ou /v2.4/, compte comme épinglé ; un segment latest explicite compte comme flottant ; et une URL sans version nulle part compte comme sans version. Il est étiqueté heuristique parce que seul le fournisseur connaît son schéma de versions — mais le point de sécurité ne dépend pas de l’étiquette : si les octets à cette URL peuvent changer sans que l’URL change, un hash SRI ne peut pas survivre, donc épinglez d’abord, calculez le hash ensuite.