Protection contre l'eskimming pour les pages et formulaires de paiement
Du JavaScript malveillant vole les données de carte directement dans le navigateur, avant que votre serveur ne traite la transaction. cside surveille chaque script sur chaque session utilisateur réelle et bloque les skimmers avant leur déclenchement.
Moniteur de page de paiement
Couverture des sessions navigateur réelles
Qu'est-ce que l'eskimming ?
L'eskimming est une cyberattaque au cours de laquelle du JavaScript malveillant est injecté dans la page de paiement d'un site web afin de voler les données de carte pendant la saisie. Le script s'exécute dans le navigateur du client. Il copie les numéros de carte de crédit, les dates d'expiration, les codes CVV et les données de facturation en temps réel, puis les envoie discrètement vers un serveur contrôlé par l'attaquant.
La transaction se termine normalement. Le client reçoit sa confirmation de commande. Le commerçant voit un paiement propre. Aucune alerte côté serveur ne se déclenche. Le temps que les cartes volées apparaissent sur le dark web, l'attaque peut déjà tourner depuis des semaines.
L'eskimming est aussi appelé web skimming, digital skimming, formjacking ou attaque Magecart. Ces noms décrivent la même menace, au niveau du navigateur.
Comment une attaque d'eskimming atteint votre page de paiement
Les attaquants n'ont pas toujours besoin d'accéder à votre propre code. La voie la plus fiable passe par les scripts tiers auxquels votre site fait déjà confiance.
Attaques de la chaîne d'approvisionnement
Un pixel analytique, une bibliothèque de test A/B, un gestionnaire de balises ou un script CDN de confiance est compromis au niveau du fournisseur. Le script provient d'un domaine approuvé, passe les contrôles CSP et se comporte normalement jusqu'à ce que le navigateur atteigne un formulaire de paiement. L'attaque Polyfill.io a montré à quelle vitesse une dépendance JavaScript de confiance peut devenir une vaste voie de distribution.
Injection directe
Les attaquants exploitent une faille CMS, un plugin non corrigé ou des identifiants admin hameçonnés pour écrire du code malveillant directement dans les modèles de page ou les configurations de gestionnaire de balises. Aucun fournisseur tiers n'est impliqué. Le skimmer est servi comme code first-party.
Exposition de quatrième partie
Vos scripts tiers chargent leurs propres dépendances. Le Web Almanac 2025 a constaté que la profondeur médiane de la chaîne d'inclusion tierce est de 3, ce qui signifie que chaque dépendance peut introduire un autre script que vous n'avez peut-être jamais examiné.
L'angle mort que partagent la plupart des piles de sécurité
L'eskimming vit entièrement dans le navigateur, côté client, pendant une session utilisateur en direct. C'est précisément là que la plupart des outils de sécurité d'entreprise cessent de regarder.
WAF et surveillance côté serveur
Un WAF surveille le trafic qui circule vers vos serveurs. L'exfiltration par eskimming part du navigateur du client directement vers un serveur de collecte de l'attaquant. Votre WAF n'observe jamais cette connexion. ISACA explique pourquoi les outils côté fournisseur ont une visibilité limitée sur le risque d'exécution du client web.
Content Security Policy
La CSP est utile, mais elle approuve des domaines, pas ce que ces domaines servent. Un script compromis provenant d'un domaine approuvé passe la CSP sans aucune alerte, et le comportement des scripts dynamiques ou inline peut malgré tout créer des failles.
Scanners externes périodiques
Les scanners s'exécutent depuis une infrastructure cloud connue, selon un calendrier. Des attaquants sophistiqués identifient l'origine de la requête et servent du code propre aux scanners tout en ciblant les vrais visiteurs entre deux fenêtres d'analyse.
Une défense au niveau du navigateur sur des sessions utilisateur réelles
cside combine la surveillance comportementale au sein des sessions utilisateur en direct avec une inspection approfondie des scripts sur l'infrastructure de cside.
Surveillance comportementale sur chaque session réelle
Un script cside léger observe le comportement de chaque script dans le navigateur : quels éléments du DOM il consulte, quels champs de formulaire il lit et quels domaines externes il contacte.
Inspection approfondie des scripts
cside récupère le contenu des scripts sur sa propre infrastructure pour une analyse alimentée par l'IA et compare les payloads aux renseignements sur les menaces recueillis sur l'ensemble des sites surveillés.
Blocage avant impact
Lorsqu'un comportement malveillant est détecté, cside empêche le script de terminer son action. Le paiement se poursuit normalement pendant que le skimmer est arrêté, avant que les données de carte ne quittent le navigateur.
Inventaire et détection des changements
cside inventorie les scripts en continu, suit les changements de payload et alerte lorsque des scripts ou des domaines non autorisés, ou des changements d'en-têtes de sécurité HTTP, apparaissent.
Les exigences 6.4.3 et 11.6.1 de PCI DSS 4.0.1 formalisent ce qu'un bon programme de prévention de l'eskimming devrait déjà faire. PCI SSC confirme que ces exigences à date d'effet différée sont entrées en vigueur le 31 mars 2025. PCI Shield de cside gère le flux de travail, de l'inventaire des scripts aux rapports hebdomadaires automatisés.
GDPR 
SOC 2 
PCI DSS Conçu pour la protection du paiement et la conformité
72,000+ sites web ont été compromis par des attaques côté client rien qu'au T2 2025.
"Une solution PCI DSS simple, avec un support exceptionnel."
