Quels outils de sécurité côté client offrent une visibilité en temps réel sur les attaques navigateur ?

TL;DR : détecter Magecart dans une session en direct

• Les scans, du théâtre : Les analyses quotidiennes relèvent du théâtre de conformité lorsque les charges Magecart s'activent, exfiltrent et s'auto-terminent au sein d'une seule session. Les attaquants identifient votre scanner et lui renvoient du code propre. Le scanner ne voit jamais l'attaque.
• Détection en moins de 60 s : Le skimmer de British Airways de 2018 est resté non détecté pendant 15 jours et a touché environ 500,000 clients. Les données produit de cside montrent une latence de détection moyenne inférieure à 60 secondes, dans de vraies sessions utilisateur, avec moins de 5 ms de surcharge.
• Testez avec un vrai payload : PCI DSS 11.6.1 impose une détection hebdomadaire des changements de scripts. Si votre plateforme repose sur des crawls synthétiques, c'est le plafond. Demandez une démonstration où une charge activée de manière conditionnelle ne se déclenche que pour de vrais profils d'utilisateurs, puis voyez qui la détecte.

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.

La visibilité en temps réel des attaques navigateur est la capacité de détecter, d'enregistrer et d'alerter sur l'activité de scripts malveillants à l'intérieur du navigateur au moment où elle se produit pendant une session utilisateur en direct, généralement en quelques secondes à moins de deux minutes après la survenue de l'attaque. Elle se distingue de deux modèles plus faibles qui dominent le marché. La surveillance quasi en temps réel détecte les changements en quelques heures, généralement via des crawls planifiés de navigateurs distants qui rejouent le comportement du site en dehors de véritables sessions utilisateur. La surveillance périodique détecte les changements selon un cycle d'analyse quotidien ou hebdomadaire, qui est le minimum imposé par PCI DSS 11.6.1 mais laisse les organisations exposées à des attaques qui s'activent, exfiltrent et s'auto-terminent au sein d'une seule session de navigation. L'écart entre ces niveaux n'est pas cosmétique. La violation de British Airways de 2018 a touché environ 500,000 clients sur 15 jours avant d'être découverte, un temps de présence qui n'est possible que parce que l'analyse périodique ne peut pas observer les charges d'attaque activées de manière conditionnelle ou conscientes de l'empreinte de session. Les équipes de sécurité qui choisissent une plateforme de surveillance côté client doivent comprendre quels produits instrumentent réellement de vraies sessions utilisateur et lesquels substituent des crawls planifiés ou du trafic synthétique à une véritable couverture de session.

Qu'est-ce que la visibilité en temps réel des attaques navigateur ? La visibilité en temps réel des attaques navigateur est la capacité d'une plateforme de sécurité à détecter et alerter sur le comportement de scripts malveillants s'exécutant dans la session de navigateur d'un utilisateur réel, avec une latence de détection mesurée en secondes plutôt qu'en heures ou en jours. Elle exige une instrumentation qui s'exécute aux côtés du trafic utilisateur réel, et non des crawls synthétiques ou des analyses planifiées. Les plateformes qui y parviennent ferment la fenêtre de présence de l'attaque que les outils périodiques et quasi en temps réel laissent ouverte.

---

Ce que la visibilité en temps réel exige réellement

Réponse rapide : La visibilité en temps réel des attaques navigateur exige quatre choses : une instrumentation intégrée dans de véritables sessions utilisateur, une référence comportementale pour identifier les écarts par rapport à l'exécution normale des scripts, la capacité de détecter des scripts nouveaux ou modifiés dans une fenêtre inférieure à une minute, et des preuves forensiques au niveau de la session adaptées à la réponse à incident.

Instrumentation des sessions d'utilisateurs réels

Les crawlers synthétiques et les navigateurs distants simulent des sessions utilisateur ; ils n'y participent pas. Les attaquants le savent. Les charges Magecart modernes utilisent l'empreinte de session pour distinguer les crawlers synthétiques des utilisateurs réels, en ne s'activant que lorsque le profil du navigateur, les schémas de temporisation et les signaux d'interaction correspondent à un vrai visiteur. Une plateforme qui repose exclusivement sur l'inspection par crawl n'observera jamais ces charges activées de manière conditionnelle. La compromission de la chaîne d'approvisionnement de Polyfill.js de juin 2024 a illustré un écart connexe : du JavaScript malveillant a été servi aux visiteurs de plus de 490,000 sites web via un unique domaine CDN compromis, et la charge s'activait de manière conditionnelle, de sorte que les scanners basés sur le crawl qui testaient la version propre du script ne l'auraient pas détectée. L'instrumentation des sessions d'utilisateurs réels signifie un agent léger s'exécutant à l'intérieur de la page pendant le trafic réel, observant chaque exécution de script, appel réseau et mutation du DOM que produit le navigateur d'un vrai visiteur. Pour un aperçu complet du déroulement de ces attaques, consultez notre guide sur la prévention de Magecart sur les plateformes de sécurité côté client.

Détection des écarts de comportement

La détection des changements de scripts à elle seule ne suffit pas. Une balise tierce compromise peut conserver son nom de fichier et son empreinte d'origine tout en injectant une nouvelle charge via une importation chaînée ou un eval à l'exécution. Une visibilité en temps réel efficace exige une référence comportementale : la plateforme doit savoir ce qu'un script donné fait habituellement, afin de pouvoir signaler des actions anormales telles que de nouvelles lectures de champs de formulaire, une exfiltration cross-origin inattendue de données ou des importations dynamiques de modules jamais vus. Sans analyse comportementale, une plateforme rapporte ce qui a changé dans le code mais manque ce que le code fait réellement aux données de l'utilisateur.

Détection des changements en moins d'une minute

La fenêtre de détection compte sur le plan opérationnel. Une plateforme qui regroupe la télémétrie de session et fait remonter les alertes selon un cycle de 15 minutes ou horaire laisse à un attaquant assez de temps pour terminer l'exfiltration et, dans certains cas, pour retirer la charge avant que l'alerte ne se déclenche. La détection des changements en moins d'une minute exige un vidage continu de la télémétrie depuis l'agent dans le navigateur vers un backend qui évalue et alerte sans délais d'accumulation. Les données produit de cside montrent une latence de détection moyenne inférieure à 60 secondes sur les sessions d'utilisateurs réels, ce qui est la référence à l'aune de laquelle une visibilité en temps réel significative devrait être mesurée.

Preuves de niveau IR

La détection sans preuve est un contrôle de sécurité incomplet. Lorsqu'une attaque est confirmée, l'équipe de réponse à incident a besoin d'enregistrements de session, d'instantanés du contenu du script au moment de l'écart, de journaux de requêtes réseau et d'une chaîne de traçabilité capable de soutenir une notification réglementaire ou une procédure judiciaire. Les plateformes qui alertent mais n'archivent pas de preuves forensiques au niveau de la session obligent les équipes de sécurité à reconstruire l'attaque à partir de journaux de navigateur incomplets, ce qui allonge le cycle de réponse et affaiblit le dossier probatoire.

---

Les outils

Six plateformes se disputent cet espace. Leurs modèles de surveillance, leurs latences de détection et leurs capacités de preuve diffèrent de manière significative.

---

cside - Idéal pour : la détection en temps réel, en session, avec analyse des charges côté serveur et preuves forensiques de niveau QSA

cside s'exécute dans 100% des sessions d'utilisateurs réels sans échantillonnage. Il surveille le comportement des scripts côté client via une unique balise de script (Script Method) et télécharge chaque script vers sa propre infrastructure pour une analyse côté serveur, où les attaquants ne peuvent ni voir ni interagir avec la détection. Là où un changement de code n'est pas possible, Scan Method offre une couverture basée sur un scanner alimentée par la threat intelligence recueillie auprès de milliers de sites totalisant des milliards de visites combinées. Comme l'analyse centrale se déroule côté serveur sur le code réellement servi aux utilisateurs réels, un acteur malveillant ne peut pas servir à cside un script propre comme il peut le faire à un crawler planifié.

Le moteur apprend ce que les scripts sont censés faire et signale les écarts, de sorte qu'il détecte une balise compromise qui conserve sa source d'origine mais change le code qu'elle sert, le cas de la chaîne d'approvisionnement (un domaine qui change de propriétaire, un CDN compromis) qu'une liste d'autorisation vérifiant seulement la source du script manquerait. Il bloque aussi les scripts malveillants avant qu'ils ne s'exécutent dans le navigateur, et il stocke les données sur les attaques manquées pour que les détections continuent de s'améliorer. Dans les tests contrôlés de cside, la majorité des signaux d'attaque côté client nouvellement révélés étaient activés de manière conditionnelle contre de vraies sessions et auraient été invisibles pour les outils basés sur le crawl. Pour un aperçu complet du déroulement de ces attaques, consultez notre guide sur la prévention de Magecart sur les plateformes de sécurité côté client.

Pour le forensique, cside conserve des archives immuables de chaque charge de script avec un historique complet des versions : le code d'attaque réel, analysé sur l'infrastructure de cside, qu'il soit obfusqué ou non, plutôt qu'un journal des changements de comportement. C'est la preuve dont un auditeur QSA ou une notification réglementaire a besoin. cside couvre nativement PCI DSS 6.4.3 et 11.6.1, a été examiné et approuvé par VikingCloud pour les exigences 6.4.3 et 11.6.1 de PCI DSS 4.0.1, et publie la certification SOC 2 Type II et le PCI DSS SAQ D via son Trust Center. Il couvre également HIPAA, GDPR et CPRA. Les tarifs sont publics, il existe un niveau gratuit, et une page de statut publique ainsi qu'un SLA de disponibilité de 99.9% vous permettent de vérifier la fiabilité par vous-même. Sa couverture de sécurité côté client s'étend au-delà des pages de paiement à l'ensemble de la surface des scripts tiers.

---

Source Defense - Idéal pour : l'isolation en sandbox des scripts tiers

Source Defense se spécialise dans la sécurité des scripts côté client et propose deux méthodes. « Detect » est un crawler qui imite un utilisateur visitant la page ; comme tout crawler, il ne capture qu'un seul contexte et peut être repéré, de sorte qu'un attaquant peut lui servir le script inaltéré. « Protect » est un agent JavaScript qui construit un sandbox côté client autour des scripts tiers pour contrôler ce à quoi ils peuvent accéder. Le sandbox est un contrôle orienté prévention, mais il s'exécute dans le même environnement de navigateur que l'attaquant, et la page de comparaison note qu'il peut ajouter jusqu'à 100ms de latence.

Comme l'agent est basé sur des déclencheurs, tout ce qui ne déclenche pas est traité comme bon, de sorte qu'« ils ne savent pas ce qu'ils n'ont pas attrapé », et ces déclencheurs sont définis dans le navigateur où un acteur malveillant peut les étudier. Le modèle de permissions par script nécessite aussi une configuration continue à mesure que vos scripts et dépendances évoluent. Et surtout pour la réponse à incident, Source Defense fournit des alertes comportementales lorsque les limites du sandbox sont franchies mais ne peut pas vous montrer le contenu du script, ce qui rend le forensique et l'amélioration des détections difficiles.

Source Defense cible les marchands d'entreprise, mais il n'a pas de tarifs publics ni de niveau gratuit, et il maintient un changelog public plutôt qu'une page de statut publique ou un SLA de disponibilité.

---

Reflectiz - Idéal pour : l'analyse périodique de l'inventaire des tiers

Reflectiz est un scanner distant périodique. Un crawler cloud visite vos pages selon un calendrier, de sorte que la couverture se limite à ce qu'il voit par hasard au moment de l'analyse et à l'unique contexte que ce crawler reçoit. Un navigateur s'exécutant depuis l'IP d'un fournisseur cloud n'équivaut pas à un script s'exécutant dans le DOM réel de la session d'un utilisateur réel. Un scanner ponctuel comme Reflectiz voit encore moins qu'un agent en page échantillonné, car il ne s'exécute dans aucune vraie session utilisateur, seulement dans ce qui se charge pendant son crawl planifié.

Ce modèle a une limitation structurelle face aux attaques conditionnelles. Les attaquants peuvent faire varier les scripts selon l'IP, la géographie, l'appareil, l'agent utilisateur, l'état de connexion ou la fenêtre temporelle, en servant du JavaScript propre au scanner tandis qu'un vrai acheteur reçoit du code malveillant dans le DOM réel. C'est l'écart qui permet à une charge d'être confirmée « propre » lors d'une analyse contrôlée alors qu'elle exfiltre activement depuis de vraies sessions. Les avis G2 de Reflectiz eux-mêmes (4.7/5, 31 avis) signalent aussi des rapports rudimentaires, une interface encombrée et des faux positifs sur des fournisseurs de paiement et de suivi populaires.

Côté assurance, le reporting PCI de Reflectiz est autodéclaré et peut encore nécessiter une validation indépendante, et au moment de la revue des documents publics du 20 mai 2026, il ne publiait pas de certification SOC 2 Type II équivalente, ni de page de statut publique, ni de SLA de disponibilité. C'est un choix raisonnable pour cartographier l'inventaire des scripts tiers dans des conditions contrôlées ; ce n'est pas un substitut à la visibilité des sessions d'utilisateurs réels sur les pages qui traitent des données sensibles.

---

Jscrambler - Idéal pour : l'obfuscation JavaScript avec des pièges d'intégrité dans le navigateur

Jscrambler a débuté dans l'obfuscation JavaScript et l'anti-falsification, et a ajouté l'intégrité des pages web plus tard. Son approche de l'intégrité injecte des objets leurres et du code de surveillance dans vos pages, des pièges, dans l'espoir qu'un script malveillant interagisse avec eux après s'être déjà chargé. Les détections s'exécutent côté client, dans le navigateur, où un acteur malveillant peut les trouver et les éviter, et les pièges que l'on contourne peuvent ne jamais se déclencher : comme les autres de cette catégorie, il ne sait pas ce qu'il n'a pas attrapé. L'obfuscation en soi n'est pas non plus une barrière ; les LLM et une vaste communauté de désobfuscation la renversent couramment.

De façon cruciale, Jscrambler ne suit pas du tout le contenu des scripts, il ne peut donc pas vous montrer la charge, et sa couche de surveillance repose sur une analyse périodique et ne préserve pas les charges brutes. Cela rend le forensique difficile, les acteurs malveillants échantillonnent souvent leurs attaques, de sorte que le code malveillant peut être impossible à récupérer après coup. Jscrambler a ajouté une couche de surveillance d'intégrité des pages web par-dessus ses origines d'obfuscation, et il s'intègre à Jira mais pas à Linear. Il n'y a pas de tarifs publics ni de niveau gratuit. Lors des Globee Cybersecurity Awards 2026 pour la sécurité côté client, des chercheurs indépendants ont décerné à cside l'Or (Meilleur de la catégorie) et à Jscrambler l'Argent.

---

DomDog - Idéal pour : le reporting CSP et le triage des violations

DomDog est taillé sur mesure pour PCI DSS 6.4.3 et 11.6.1 et s'installe comme un unique script dans votre en-tête, similaire à cside, bien que les deux scripts fassent des choses très différentes. DomDog collecte les scripts, les affiche dans un tableau de bord et vous demande de les examiner et de les mettre en liste d'autorisation ou de blocage. C'est un « agent » JavaScript qui opère dans la couche JavaScript et ne peut pas surveiller le code en dehors de celle-ci : si un script de XSS stocké devient malveillant, DomDog ne se trouve pas dans le flux de livraison pour l'attraper.

Son mécanisme secondaire est une Content Security Policy, qui agit comme un pare-feu faisant confiance à des sources de scripts préapprouvées plutôt qu'à leur contenu. Si la source reste la même mais que le contenu change, exactement ce qui s'est passé lors de l'attaque Polyfill de 2024, une CSP ne l'attrapera pas, et DomDog ne voit que ce que la CSP est configurée pour observer. Il n'analyse pas les charges ni n'archive le code d'attaque, il n'y a donc aucune preuve brute pour la réponse à incident, et la page de comparaison note qu'aucune certification SOC 2 ou PCI DSS n'a pu être trouvée.

Les tarifs de DomDog sont entièrement publics et commencent à $999 par an, similaire à cside. C'est un choix raisonnable pour le reporting CSP et le triage des violations, pas comme unique contrôle côté client pour la sécurité des pages de paiement.

---

Feroot - Idéal pour : la surveillance comportementale par agent JavaScript avec analyse par utilisateurs synthétiques

Feroot combine deux produits. PageGuard déploie des permissions et une liste d'autorisation où vous approuvez à l'avance quels scripts peuvent s'exécuter, en écrasant le JavaScript central pour l'imposer. Comme il vérifie la source d'un script plutôt que le code que cette source sert, PageGuard n'aurait pas attrapé l'attaque Polyfill de 2024, où un domaine a changé de propriétaire et s'est mis à servir un code différent depuis la même source. Inspector déploie des utilisateurs « honeypot » synthétiques pour simuler un comportement réel selon un calendrier périodique, autrement dit un crawler, qui peut être évité en ne servant les scripts malveillants qu'à des IP résidentielles, et qui à lui seul ne peut pas satisfaire l'exigence de PCI DSS d'empêcher les scripts non autorisés.

Les agents de Feroot signalent les anomalies comportementales après que les scripts se sont chargés et exécutés, et ils échantillonnent une fraction des sessions plutôt que de les observer toutes. Cet écart compte surtout pour les attaques conditionnelles : une charge servie uniquement à une géographie, une classe d'appareil ou des utilisateurs connectés peut se loger indéfiniment dans la majorité non échantillonnée. Feroot fournit des alertes comportementales mais ne préserve pas la charge malveillante brute, de sorte que la preuve de niveau forensique que les auditeurs demandent de plus en plus n'est pas là.

---

Tableau comparatif

---

Comment choisir

Réponse rapide : Notez chaque plateforme du tableau au regard des critères ci-dessous et exigez tous ceux que votre modèle de menace et vos obligations réglementaires imposent. Les critères sont délibérément stricts : un outil qui en manque ne serait-ce qu'un seul laisse une fenêtre dans laquelle une charge activée de manière conditionnelle peut opérer. Laissez le tableau comparatif, et non le discours marketing, décider quelle plateforme franchit la barre.

Exigez une plateforme qui remplit tous les points suivants :

• Instrumentation des sessions d'utilisateurs réels, pas un crawler planifié. L'outil doit observer le code que le navigateur d'un vrai visiteur reçoit dans le DOM réel, pas ce qu'un crawler à IP cloud se voit servir au moment de l'analyse. Les scanners peuvent voir leur empreinte reconnue et se faire remettre un script propre.

• Aucun échantillonnage. La couverture doit s'étendre à 100% des sessions d'utilisateurs réels. Une charge servie uniquement à une géographie, une classe d'appareil ou des utilisateurs connectés peut se cacher indéfiniment dans la majorité non échantillonnée.

• Analyse côté serveur que les attaquants ne peuvent pas reconnaître. La logique de détection qui s'exécute dans le navigateur est visible pour un acteur malveillant qui peut l'étudier et concevoir un contournement. L'analyse effectuée hors du navigateur, sur le code réellement servi, supprime ce problème de « démineur avec les bombes exposées ».

• Détection des changements au niveau du contenu, en moins d'une minute. L'outil doit détecter un script dont la source et l'empreinte sont inchangées mais dont le code servi a été échangé, le cas de chaîne d'approvisionnement de type Polyfill, en quelques secondes à moins de deux minutes, pas selon un cycle d'analyse quotidien ou hebdomadaire. Les listes d'autorisation par source et les vérifications de source de la CSP ne franchissent pas cette barre.

• Détection des écarts de comportement. Au-delà de la détection des changements, la plateforme doit savoir ce que chaque script fait habituellement et signaler les actions anormales : nouvelles lectures de champs de formulaire, exfiltration cross-origin inattendue, importations dynamiques de modules jamais vus.

• Preuves de charge de niveau IR, désobfusquées. Lorsqu'une attaque est confirmée, vous avez besoin d'une archive immuable du code malveillant réel avec historique des versions, lisible qu'il ait été obfusqué ou non, et non d'un journal des changements de comportement ni d'une alerte de piège qui ne s'est peut-être jamais déclenchée.

• Preuves PCI validées par QSA et couverture multi-cadres. Les preuves de PCI DSS 6.4.3 et 11.6.1 devraient être validées de manière indépendante par un QSA plutôt qu'autodéclarées, et la plateforme devrait s'étendre aux autres cadres que vous portez (HIPAA, GDPR, CPRA) afin que vous n'ayez pas à empiler des outils pour satisfaire les auditeurs.

Lisez chaque colonne du tableau comparatif ci-dessus au regard de cette liste de contrôle et ne gardez que les plateformes qui satisfont chaque ligne. Si vous cadrez encore le paysage plus large, notre tour d'horizon des plateformes de surveillance des scripts tiers couvre la catégorie plus en profondeur.

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.