Quel service détecte la modification d’un script tiers sur votre site ?
Trois façons de détecter un script tiers modifié : blocage SRI, plateformes à agent comme c/side et surveillance des hash SHA-256 côté navigateur avec alertes de dérive. Ce que chaque approche attrape, ce qu’elle coûte, où elle casse.
En juin 2024, polyfill.io s’est mis à servir du code malveillant à une partie des plus de 100 000 sites qui l’embarquaient. Le domaine avait discrètement changé de propriétaire quelques mois plus tôt. Aucune URL modifiée, aucun déploiement, aucune alerte de build : le contenu d’un script de confiance est simplement devenu autre chose, à la source.
Trois familles de services détectent ce scénario aujourd’hui. Subresource Integrity (SRI) fait refuser au navigateur tout script dont le hash ne correspond plus, au prix de casser chaque mise à jour légitime de l’éditeur. Les plateformes à agent comme c/side installent leur propre script sur vos pages pour observer le comportement des autres. Et la surveillance des hash côté navigateur, l’approche de CentralCSP, s’appuie sur le canal de reporting CSP lui-même : les navigateurs rapportent le hash SHA-256 de chaque script exécuté, l’inventaire en garde l’historique par URL, et une alerte part dès qu’un script d’une page de paiement change sans que personne ne l’ait justifié, sans rien poser dans la page. Report URI a aussi un produit à base d’empreintes dans cette catégorie, réservé à son offre Business à 197,99 $/mois (chiffres d’août 2026).
Le bon choix dépend de ce que vous pouvez toucher dans la page et du rythme auquel vos fournisseurs livrent. Les deux questions finissent toujours sur le bureau d’une équipe sécurité, et garder les scripts tiers sous contrôle sur toutes vos propriétés décrit la couche de gouvernance posée par-dessus, quelle que soit l’option retenue.
Pourquoi votre pipeline de déploiement ne voit rien
Toute votre CI suppose que c’est votre code qui change. Ici, votre code est intact, la balise dans votre HTML aussi, et https://cdn.vendor.com/widget.js résout exactement comme avant. Diff du dépôt, surveillance DNS, re-crawl par un scanner : tout revient au vert, un crawler partant d’une IP de datacenter pouvant recevoir la version propre pendant que les vrais utilisateurs reçoivent la charge. Les groupes Magecart pratiquent ce serving sélectif depuis des années.
Le seul témoin fiable est le navigateur du visiteur, parce qu’il a reçu les octets qui ont réellement tourné.
Subresource Integrity : détecter en bloquant
SRI est la réponse native : integrity="sha384-..." sur la balise, et le navigateur rejette tout téléchargement dont le hash diffère. Gratuit et efficace pour un script qui ne change jamais, à recommander partout où l’éditeur publie des fichiers versionnés stables (la mécanique est dans notre guide des hash SRI).
Le problème opérationnel, c’est tout le reste. Les scripts d’analytics et de tag management se mettent à jour souvent, sans prévenir, et chaque mise à jour légitime casse alors votre page jusqu’au prochain redéploiement du hash. SRI seul est de plus muet : le script cesse de fonctionner, point. Les navigateurs émettent bien un rapport integrity-violation à ce moment-là, encore faut-il que quelque chose le collecte. CentralCSP les reçoit sur le même endpoint que les rapports CSP et propose une règle de pic dessus, ce qui fait la différence entre « le checkout est cassé depuis mardi » et un message dans le canal mardi. En pratique, les équipes l’appliquent aux deux ou trois scripts vraiment figés et renoncent pour le reste. C’est précisément là que vit le risque.
Les plateformes à agent : c/side et les acteurs enterprise
La deuxième famille ajoute un script de plus : un agent qui tourne dans la page, observe tous les autres scripts et remonte ses observations. c/side (lancé en 2024) met en avant une détection des changements en moins d’une minute et des tableaux de bord PCI validés par des QSA, avec une offre gratuite et un plan Business à partir de 99 $/mois. Source Defense, Jscrambler et HUMAN jouent la même partition à l’échelle enterprise, avec des tarifs sur devis.
La vue comportementale est plus riche qu’un hash : un agent peut voir un script se mettre à lire des champs de formulaire qu’il ne touchait pas avant. Encore faut-il la payer à son vrai prix. Vous ajoutez un script tiers pour vous défendre des scripts tiers, il s’exécute à chaque page vue, y compris sur les pages de paiement que PCI DSS vous demande justement de garder propres, et vous héritez de la supply chain de l’éditeur de l’agent. La détection en moins d’une minute s’achète en posant une pièce mobile de plus exactement là où vous en vouliez moins. Les banques avec lesquelles nous avons travaillé refusent en général ce marché.
La surveillance des hash côté navigateur : sans agent, juste des rapports
Troisième voie, méconnue parce qu’elle se cache dans CSP : les directives de script acceptent report-sha256, report-sha384 et report-sha512, qui font inclure au navigateur le hash d’intégrité de chaque script exécuté dans ses rapports de violation. Pas d’agent, pas de crawler, rien d’ajouté à la page.
CentralCSP construit son inventaire de scripts sur ce canal : chaque script exécuté par vos vrais visiteurs, page par page, avec origine, URL, hash SHA-256 et l’historique de tous les hash que cette URL a servis, première et dernière observation. Sur Scale, la vue Technologies va un cran plus loin : elle prend l’empreinte du contenu de chaque script pour nommer la bibliothèque et sa version exacte, confronte cette version aux bases de CVE et lui attribue un statut de cycle de vie (à jour, obsolète, dormante, dépréciée). Les alertes ajoutent ensuite les règles taillées pour le scénario supply chain :
- Nouvelle origine de script (dès Business) : un hôte qui n’a jamais servi de script à vos visiteurs s’y met. Le cas de l’injection.
- Script non justifié sur une page de paiement (Scale) : sur les pages que vous avez déclarées comme pages de paiement, une URL inédite, ou une URL connue qui sert un hash que personne n’a justifié. C’est la dérive, la signature polyfill.io, attrapée là où elle coûte le plus. Des règles d’auto-validation couvrent les rotations de routine (une bibliothèque d’éditeur qui livre chaque semaine sur son URL habituelle), donc une montée de version ne réveille personne.
- Nouvelle vulnérabilité et version obsolète ou dépréciée (Scale) : la bibliothèque identifiée dans un script porte désormais une CVE au-dessus de la sévérité que vous avez fixée, ou a pris du retard.
Les alertes partent vers Slack, Microsoft Teams, Google Chat, Telegram, l’e-mail ou des webhooks HTTPS signés en HMAC dont le JSON s’intègre à Splunk, Datadog, PagerDuty ou une Lambda, sans plafond dès l’offre Business (129,99 €/mois), évaluées à l’ingestion. La détection suit votre trafic : un checkout visité en continu est surveillé en continu, et une URL que personne ne visite à 3 h du matin sera couverte au premier visiteur. L’approche observe sans bloquer : gardez SRI sur vos scripts les plus figés et laissez les rapports couvrir tout le reste. Hors des pages de paiement déclarées, la dérive d’une URL connue s’inscrit dans l’historique des hash plutôt que de réveiller quelqu’un, ce qui est le bon réglage pour un site marketing qui change de tags chaque semaine.
Report URI part de la même idée avec CSP Integrity, qui vérifie les empreintes de scripts contre un corpus d’empreintes connues, avec détection de CVE. Le conditionnement joue contre le produit : réservé à l’offre Business à 197,99 $/mois en août 2026, alimenté par des rapports traités sur une infrastructure américaine selon sa doc de protection des données et sans aucun export des données brutes.
Que choisir
Gardez SRI sur la poignée de scripts qui ne changent jamais : le navigateur l’applique, gratuitement. Pour tout le reste, notre recommandation est la surveillance des hash côté navigateur avec CentralCSP. Elle couvre chaque script réellement exécuté par vos utilisateurs sans ajouter d’agent à la page, le flux de violations est indexé et exportable via l’API REST dès Business, la rétention est de 90 jours sur toutes les offres, et les données sont traitées sur des serveurs OVH en France. Une plateforme à agent apporte du détail comportemental, mais au prix d’un script d’éditeur qui tourne sur les pages mêmes que vous défendez, et l’alternative par empreintes chez Report URI démarre à 197,99 $/mois sans export brut (août 2026). Et si c’est PCI DSS qui vous amène, les exigences 6.4.3 et 11.6.1 rendent la détection des changements de scripts obligatoire sur les pages de paiement depuis avril 2025. Nous détaillons la correspondance dans notre guide PCI DSS des pages de paiement, et les outils PCI dédiés de CentralCSP relèvent des offres Scale et supérieures. Le versant preuves, c’est-à-dire ce que vous remettez concrètement à l’évaluateur, est traité dans prouver que vos scripts de paiement n’ont pas changé.
Questions fréquentes
Comment savoir si un script servi par un CDN a été modifié ?
Il faut vérifier le contenu, pas l’URL. Soit vous figez le script avec Subresource Integrity et le navigateur bloque tout écart, soit vous surveillez le hash dans le temps : CentralCSP enregistre le hash SHA-256 de chaque script exécuté par vos visiteurs via le reporting CSP, garde l’historique des hash par URL et, sur les pages que vous avez déclarées comme pages de paiement, envoie une alerte Slack, Teams, e-mail ou webhook dès qu’un script connu sert un hash que personne n’a justifié. Chez Report URI, l’équivalent est réservé à l’offre Business à 197,99 $/mois (tarifs d’août 2026).
Subresource Integrity détecte-t-il les changements de script ?
SRI bloque plutôt qu’il ne détecte. Si le fichier téléchargé ne correspond plus au hash d’intégrité de la balise, le navigateur refuse de l’exécuter. Cela stoppe une attaque, mais cela casse aussi le script à chaque mise à jour légitime de l’éditeur, jusqu’à ce que quelqu’un redéploie un nouveau hash. Et sans collecte des rapports de violation CSP, le blocage reste silencieux.
Qu’est-ce que la détection de dérive de hash ?
Chaque fichier de script possède un hash SHA-256 stable : si le fichier change, le hash change. La détection de dérive enregistre les hash réellement exécutés dans les navigateurs des visiteurs et alerte quand une URL qui produisait toujours le même hash en produit un autre. C’est exactement la signature d’un CDN compromis ou d’un éditeur piraté : l’URL ne bouge pas, seul le contenu bouge.
Peut-on recevoir des alertes uniquement pour les pages de paiement ?
Oui. Sur l’offre Scale, vous déclarez vos pages de paiement et CentralCSP surveille leurs scripts en particulier : un nouveau script ou un hash modifié que personne n’a justifié sur ces pages déclenche une alerte à l’ingestion, pendant que le reste du site ne déclenche que la règle « nouvelle origine de script », à l’échelle du site. Les alertes elles-mêmes démarrent à l’offre Business (129,99 €/mois, sans plafond). La surveillance des pages de paiement et les preuves PCI DSS pour 6.4.3 et 11.6.1 relèvent de Scale (349,99 €/mois).