Résumé : surveillance des scripts
La surveillance des scripts est l'observation continue de ce que JavaScript exécute dans le navigateur d'un visiteur en temps réel : quels scripts se chargent, quelles données ils accèdent, où ils écrivent et quels scripts ils importent dynamiquement. Contrairement à l'inventaire ou aux contrôles de hachage, la surveillance des scripts suit le comportement afin qu'un script fournisseur compromis soit détecté non par un changement d'URL, mais par des actions modifiées.
- Ce qu'exige PCI DSS : L'inventaire continu et la détection des changements que la norme PCI DSS 4.0.1 exige pour chaque script sur une page de paiement.
- Au-delà des allowlists : Les listes d'autorisation statiques manquent les domaines de confiance compromis. La détection réelle consiste à observer ce que le script lit et transmet réellement, pendant la session.
- Ce qu'il faut rechercher : capteur first-party, comparaison de la charge utile et pas seulement du hachage, faible taux de faux positifs sur du trafic réel, exports de preuves pour QSA.
Peu de temps ? Découvrez le blocage de Magecart et de skimmers dans le navigateur par cside. Elle couvre tout ce qui suit en un seul déploiement.
Ce qu'exige une surveillance efficace des scripts tiers
Réponse rapide : Une surveillance efficace des scripts tiers va au-delà du suivi des scripts présents. Elle détecte les changements dans ce que font les scripts à l'exécution : les données auxquelles ils accèdent, les destinations vers lesquelles ils écrivent, les importations dynamiques qu'ils chargent. Une compromission de la chaîne d'approvisionnement produit souvent un nouveau hachage depuis une origine de confiance ; seule la surveillance comportementale la détecte.
Le Top 10 2021 de l'OWASP répertorie les défaillances d'intégrité des logiciels et des données, qui couvrent les attaques de la chaîne d'approvisionnement logicielle, parmi les trois principaux risques des applications web (OWASP). Les cinq capacités qui comptent spécifiquement pour la surveillance des scripts tiers sont :
Comment une compromission de la chaîne d'approvisionnement atteint le navigateur :
- L'attaquant compromet l'infrastructure CDN du fournisseur et modifie un script chargé par des milliers de sites, par exemple
cdn.vendor.com/analytics.js. Le marchand n'a jamais touché au code. - Le fichier modifié est livré comme un nouveau fichier avec un nouveau hachage valide depuis l'origine de confiance. Le CSP le laisse passer (l'origine est autorisée). La surveillance du SRI / de la rotation de hachage le laisse passer (un nouveau hachage d'un fournisseur connu est attendu). Le WAF / CDN le laisse passer (TLS valide, livraison légitime). Les contrôles d'identité voient une origine de confiance, ils ne voient pas le comportement.
- Le script s'exécute dans le navigateur du visiteur sur le formulaire de paiement ou de commande et lit des champs de formulaire qu'il n'avait jamais lus auparavant.
- Il envoie par POST les données de carte volées vers une nouvelle destination réseau, le point de terminaison d'exfiltration de l'attaquant, que la référence n'a jamais incluse.
- Seule la surveillance comportementale à l'exécution la détecte. Un capteur d'exécution cside signale la déviation (une nouvelle lecture de champ de formulaire plus une nouvelle destination sortante) dès la première session réelle où la version compromise s'exécute. Les contrôles d'identité et de hachage ne le peuvent pas, car le script est autorisé mais compromis.
Inventaire statique face à l'arbre de dépendances à l'exécution :
| Vue | Ce qu'elle contient |
|---|---|
| Statique, ce que la page déclare | Trois balises de script déclarées dans le HTML de la page au chargement : analytics.js, tag-manager.js et cdn-vendor[.]example/widget.js. C'est tout l'inventaire que voit un scanner. |
| Exécution, ce qui s'exécute réellement | cdn-vendor[.]example/widget.js charge fonts.css et vendor-core.js ; vendor-core.js importe ensuite dynamiquement import('cdn-metrics[.]example/p.js'). |
La charge utile importée dynamiquement, cdn-metrics[.]example/p.js, injectée à l'exécution par vendor-core.js, n'apparaît jamais dans l'inventaire statique. Seule une plateforme qui surveille l'environnement d'exécution en temps réel voit les niveaux deux et trois de l'arbre de dépendances, là où se cachent les charges utiles de la chaîne d'approvisionnement.
Cartographie des relations fournisseurs. La plateforme doit énumérer non seulement quels scripts sont présents, mais quel fournisseur livre chaque script, via quelle infrastructure et quels autres scripts chaque script charge dynamiquement. Une attaque de la chaîne d'approvisionnement se propage souvent à travers un arbre de dépendances.
Référence comportementale par script. Lorsque le script d'analytique du fournisseur X est compromis, la nouvelle version peut avoir la même URL et un nouveau hachage d'apparence légitime, mais elle lira des champs du formulaire de paiement ou écrira vers une nouvelle destination réseau. Détecter cela exige une référence comportementale, pas seulement une référence d'identité.
Détection des importations dynamiques. Les scripts qui chargent d'autres scripts à l'exécution sont le vecteur de propagation de la chaîne d'approvisionnement le plus courant. Une plateforme qui ne surveille que les scripts déclarés statiquement dans le HTML manquera les dépendances de deuxième niveau chargées dynamiquement.
Surveillance des destinations réseau. Le signal ultime d'un skimmer de chaîne d'approvisionnement réussi est une transmission de données vers une destination que la référence n'incluait pas. Surveiller les appels réseau sortants de chaque script (domaine, méthode, forme de la charge utile) est le signal de détection de chaîne d'approvisionnement le plus fiable.
Notation du risque fournisseur. Tous les fournisseurs ne présentent pas le même risque de chaîne d'approvisionnement. Une plateforme qui attribue et met continuellement à jour des scores de risque fournisseur en fonction du comportement observé, de la sécurité de l'infrastructure de livraison et des schémas historiques de compromission offre aux équipes de sécurité une vue priorisée de leur surface d'exposition aux tiers.
Les plateformes
cside
Idéal pour : Les équipes de sécurité et d'ingénierie qui ont besoin d'une visibilité complète sur la chaîne d'approvisionnement JavaScript tierce à l'exécution, avec référence comportementale, détection des importations dynamiques et archivage des charges utiles de qualité forensique.
cside ajoute un script à votre site, surveille ce que fait chaque script tiers dans des sessions d'utilisateurs réels et télécharge chaque script vers sa propre infrastructure pour une analyse côté serveur. Comme l'analyse principale se déroule hors de la page, elle reste invisible pour les attaquants : il n'y a aucun piège ni crochet dans le navigateur qu'ils pourraient étudier, désactiver ou contourner. cside construit une référence comportementale pour chaque script, en suivant les lectures du DOM, les attachements de gestionnaires d'événements, les écritures réseau et les importations dynamiques, et signale la déviation par rapport à cette référence dès la première session d'utilisateur réel où une version compromise s'exécute.
La couverture est de 100 % des sessions d'utilisateurs réels sans échantillonnage, ce qui compte le plus pour les attaques conditionnelles : une charge utile servie uniquement à une zone géographique, une classe d'appareil ou des utilisateurs connectés. La détection des importations dynamiques atteint les deuxième et troisième niveaux de l'arbre de dépendances, le chemin de propagation le plus courant des attaques de la chaîne d'approvisionnement, et chaque charge utile est conservée dans une archive immuable afin que la réponse aux incidents et les auditeurs QSA obtiennent le code d'attaque réel plutôt qu'un journal comportemental. Le même moteur aide les équipes à satisfaire les exigences 6.4.3 et 11.6.1 de PCI DSS 4.0.1, ainsi que HIPAA, GDPR et CPRA. Les prix sont publics et il existe une offre gratuite. Cette approche à l'exécution est le même modèle que celui des outils de visibilité des attaques navigateur en temps réel et de la catégorie plus large de la sécurité côté client.
Lors des Globee® Cybersecurity Awards 2026, un jury indépendant a désigné cside lauréat du Globee® d'Or (Meilleur de la catégorie) pour la Sécurité côté client ; Jscrambler a reçu l'Argent. Voir le comparatif direct cside vs Jscrambler.
Jscrambler
Idéal pour : Les équipes de développement qui veulent protéger leur propre JavaScript first-party contre l'altération tout en surveillant les scripts tiers.
Jscrambler a débuté dans l'obfuscation JavaScript, transformant le code first-party pour compliquer sa rétro-ingénierie, et a ajouté plus tard sa couche de surveillance Webpage Integrity. Pour les équipes qui doivent aussi protéger une logique propriétaire dans le navigateur, l'application de licences ou des algorithmes, le portefeuille combiné est un attrait véritable, et le comparatif cside vs Jscrambler couvre ce recoupement en détail.
Côté chaîne d'approvisionnement, la surveillance repose sur des pièges : Jscrambler injecte des objets leurres et du code de surveillance dans vos pages et attend qu'un script malveillant interagisse avec eux après qu'il s'est déjà chargé. Ces pièges s'exécutent dans le navigateur, où un attaquant motivé peut les voir, ignorer les leurres ou bloquer le point de terminaison de rappel. Comme Jscrambler ne suit pas le contenu des scripts, il ne peut pas vous montrer la charge utile après un incident, ce qui limite l'analyse forensique. cside exécute son analyse côté serveur, là où les attaquants ne peuvent pas la voir, et archive le code malveillant réel pour examen. Jscrambler a reçu le Globee® d'Argent face à l'Or de cside dans la catégorie Sécurité côté client 2026.
Source Defense
Idéal pour : Les marchands d'entreprise qui veulent contenir les scripts tiers via un sandboxing et une isolation côté client.
Source Defense, fondée en 2014, sécurise les scripts tiers de deux façons. « Source Defense Detect » est un robot d'exploration qui imite un visiteur et récupère les scripts qu'une page charge ; comme un robot n'est qu'un seul contexte (localisation, appareil, heure), il ne peut pas capturer la charge utile exacte qu'un visiteur réel reçoit, et un attaquant peut servir un script propre chaque fois que la requête semble provenir d'un fournisseur cloud. « Source Defense Protect » est un agent JavaScript qui construit un sandbox côté client pour restreindre ce qu'un script peut atteindre sur la page.
L'idée du sandbox est solide, mais il s'exécute dans le même environnement de navigateur que l'attaquant, de sorte qu'un script malveillant déjà en cours d'exécution peut redéfinir des fonctions essentielles comme fetch et couper les alertes propres à l'agent. Le comparatif cside vs Source Defense note également jusqu'à 100 ms de latence ajoutée et l'angle mort basé sur les déclencheurs où tout ce qui ne se déclenche pas est supposé sain. Comme les autres outils basés sur un agent, Source Defense ne peut pas vous montrer le contenu du script, ce qui limite l'analyse forensique. cside analyse chaque script côté serveur avant qu'il ne soit approuvé, maintient une couverture de 100 % des sessions sans échantillonnage et conserve la charge utile brute comme preuve.
DomDog
Idéal pour : Les équipes qui veulent un outil ciblé et peu coûteux visant directement PCI DSS 6.4.3 et 11.6.1, avec une tarification transparente.
DomDog est taillé sur mesure pour les exigences 6.4.3 et 11.6.1 de PCI DSS 4.0.1 et, fait inhabituel dans ce domaine, publie ouvertement sa tarification, à partir de 999 $ par an, similaire à cside. La configuration se résume à un seul script dans la balise d'en-tête. Il collecte les scripts qui s'exécutent sur vos pages, les affiche dans un tableau de bord et vous demande de les examiner et de les mettre en liste d'autorisation ou de blocage, soutenu par une couche secondaire de Content Security Policy (CSP).
Cette conception est un « agent » JavaScript qui ne se place pas dans le flux de livraison des scripts, de sorte qu'un script XSS stocké qui devient malveillant plus tard peut passer inaperçu, et la couche CSP ne fait confiance qu'à la source d'un script, pas au code servi : elle ne détecterait pas une source qui conserve son domaine mais change son contenu, comme dans l'attaque Polyfill. Le comparatif cside vs DomDog n'a pas non plus pu trouver de certification SOC 2 ou PCI DSS pour DomDog. cside se place sur le chemin de livraison, télécharge et analyse la charge utile réelle côté serveur, l'archive et couvre des cadres au-delà de PCI, dont HIPAA, GDPR et CPRA.
Feroot Security
Idéal pour : Les équipes axées sur la conformité qui veulent un moniteur comportemental basé sur un agent JavaScript pour la visibilité des scripts PCI DSS.
Feroot, fondée en 2017, scinde son offre en deux produits. « PageGuard » déploie des permissions et une liste d'autorisation où vous approuvez au préalable quels scripts peuvent s'exécuter sur quelles pages, en réécrivant le JavaScript de base pour appliquer la politique. Comme une liste d'autorisation ne vérifie que la source d'un script, pas le code servi, le comparatif cside vs Feroot note que PageGuard n'aurait pas détecté l'attaque Polyfill, où un domaine de confiance a changé de mains et s'est mis à servir du nouveau code. « Inspector » déploie des utilisateurs pots de miel synthétiques pour simuler un comportement réel ; c'est en réalité un scanner qui effectue des contrôles périodiques, et un robot peut être contourné en servant le script malveillant uniquement à des adresses IP résidentielles.
Les agents de Feroot signalent les anomalies comportementales après le chargement des scripts et n'échantillonnent qu'une fraction des sessions, de sorte qu'une charge utile servie à une zone géographique, une classe d'appareil ou des utilisateurs connectés peut rester indéfiniment dans la majorité non échantillonnée. cside télécharge chaque script pour une analyse côté serveur en temps réel sur 100 % des sessions sans échantillonnage, et archive chaque charge utile pour l'analyse forensique et la preuve PCI.
Comparatif en bref
| Plateforme | Référence comportementale | Détection des importations dynamiques | Surveillance des destinations réseau | Notation du risque fournisseur | Preuve désobfusquée |
|---|---|---|---|---|---|
| cside | Oui | Oui | Oui | Partiel | Oui |
| Jscrambler | Partiel | Non documenté dans ce comparatif | Non documenté dans ce comparatif | Non | Non |
| Source Defense | Sandboxing | Non documenté dans ce comparatif | Non documenté dans ce comparatif | Non documenté dans ce comparatif | Non |
| DomDog | DOM uniquement | Non | Non | Non | Non |
| Feroot | Limitée | Non | Non documenté dans ce comparatif | Non | Non |
Comment choisir
Réponse rapide : Ne partez pas d'un nom de produit. Décidez de votre objectif de contrôle principal, puis exigez les capacités dont il dépend. Notez chaque outil du tableau comparatif selon la même liste de contrôle et laissez celui qui satisfait tous vos incontournables se désigner de lui-même.
Utilisez cette liste de contrôle. Les critères qui séparent un vrai contrôle de la chaîne d'approvisionnement d'un simple tableau de bord d'inventaire sont ceux qu'une charge utile compromise et obfusquée ne peut pas franchir :
- Référence comportementale en sessions réelles. L'outil apprend ce que chaque script fait normalement (lectures du DOM, gestionnaires d'événements, écritures réseau) et signale la déviation, plutôt que de seulement vérifier l'identité ou le hachage d'un script.
- Couverture de 100 % des sessions d'utilisateurs réels, sans échantillonnage. Les attaques conditionnelles servent la charge utile malveillante uniquement à une zone géographique, une classe d'appareil ou des utilisateurs connectés. Toute couverture inférieure au total peut laisser cette charge utile indéfiniment dans la majorité non échantillonnée.
- Traçage des importations dynamiques. La détection atteint les deuxième et troisième niveaux de l'arbre de dépendances, les scripts chargés par des scripts, ce qui est le chemin de propagation de la chaîne d'approvisionnement le plus courant.
- Surveillance des destinations réseau. Les appels sortants par script (domaine, méthode, forme de la charge utile) sont suivis, de sorte que l'exfiltration vers une nouvelle destination est détectée même quand l'origine du script est autorisée.
- Analyse de la charge utile côté serveur que les attaquants ne peuvent ni identifier ni contourner. La détection principale s'exécute hors de la page, il n'y a donc aucun piège, crochet ni agent dans le navigateur qu'un attaquant puisse voir, désactiver ou redéfinir.
- Archivage des charges utiles désobfusquées pour l'analyse forensique. Le code malveillant réel est capturé et conservé dans un enregistrement immuable, et pas seulement un journal de changements comportementaux, afin que la réponse aux incidents et un QSA obtiennent la preuve réelle.
- Preuve de qualité QSA pour PCI DSS 6.4.3 et 11.6.1, idéalement aux côtés de HIPAA, GDPR et CPRA, pour qu'un seul contrôle serve plusieurs cadres de conformité.
- Fonctionne sur n'importe quel CDN avec un seul script et sans maintenance de liste d'autorisation, évitant l'écriture de règles par script et le verrouillage fournisseur à mesure que vos intégrations changent.
- Tarification transparente et offre gratuite, afin de valider la couverture sur votre propre trafic avant d'engager un budget.
Pondérez la liste de contrôle vers votre objectif principal, puis lisez le tableau comparatif ci-dessus et choisissez l'outil qui satisfait chaque incontournable. Pour la classe apparentée des attaques de skimming, consultez notre panorama des plateformes de sécurité côté client pour la prévention de Magecart.
Essayez cside avant d'acheter. cside propose un plan gratuit : vous pouvez vous inscrire, le déployer et explorer la plateforme par vous-même, sans appel commercial ni processus d'achat. Et notre équipe de support est à portée de message dès que vous avez besoin d'aide.
