Les attaques par vol de données (data skimming) dérobent les informations de carte de paiement directement depuis le navigateur de vos clients. Ces attaques opèrent entièrement côté client, ce qui signifie que votre WAF, votre SIEM et vos journaux serveur ne voient rien d'anormal pendant que les numéros de carte affluent vers des serveurs contrôlés par les attaquants. Selon une étude de DataDome, les attaques Magecart ont compromis plus de 2 millions de sites web dans le monde depuis la première attaque exécutée à grande échelle en 2015.
cside surveille les scripts tiers au moment où ils s'exécutent dans de vraies sessions de navigateur, détectant l'exfiltration de données non autorisée et les changements de scripts en moins de 60 secondes en moyenne. Cet article explique ce qu'est la protection contre le vol de données, comment ces attaques fonctionnent et ce que vous pouvez faire pour les arrêter.
Points clés : qu'est-ce que la protection contre le vol de données pour l'e-commerce
- La protection contre le vol de données surveille les scripts exécutés par le navigateur afin de détecter et bloquer le vol de paiement avant que les données de carte n'atteignent les attaquants.
- Les attaques Magecart et de formjacking injectent du JavaScript malveillant dans les pages de paiement, opérant entièrement côté client, là où les outils de sécurité serveur ne peuvent pas les voir.
- Les exigences 6.4.3 et 11.6.1 de PCI DSS 4.0.1 imposent désormais l'inventaire des scripts, la surveillance de l'intégrité et la détection des changements sur les pages de paiement.
- cside automatise la surveillance des scripts, détecte les changements non autorisés et génère des rapports prêts pour l'audit que les QSA acceptent pour la conformité PCI.
- Les outils de sécurité traditionnels comme les WAF et les CSP ne peuvent pas détecter le comportement des scripts à l'exécution, laissant les pages de paiement vulnérables aux attaques de la chaîne d'approvisionnement.
Qu'est-ce que le vol de données dans l'e-commerce ?
Le vol de données est une attaque basée sur le navigateur où du JavaScript malveillant capture les données de carte de paiement au moment où les clients les saisissent sur les pages de paiement. L'attaque se produit dans le navigateur du client après que votre serveur a livré une page propre. Votre infrastructure back-end voit une transaction normale pendant que l'attaquant reçoit une copie de chaque frappe au clavier.
Le nom « Magecart » désigne plusieurs groupes de pirates qui ont été les pionniers de cette technique, ciblant à l'origine le logiciel de panier d'achat Magento. Aujourd'hui, le terme décrit toute attaque de skimming web qui injecte du code malveillant dans des scripts tiers légitimes ou directement dans les pages de paiement.
Les attaquants obtiennent généralement l'accès par l'un de trois points d'entrée : la compromission directe du site web via des vulnérabilités du CMS, les attaques de la chaîne d'approvisionnement sur des fournisseurs tiers, ou des espaces de stockage cloud mal configurés contenant des ressources du site. Une fois à l'intérieur, ils implantent du code de skimming qui se fond dans les scripts légitimes de traitement des paiements.
Comment fonctionnent les attaques par vol de données ?
Les attaques par vol de données suivent un processus en trois étapes : infiltration, implantation et exfiltration. Comprendre chaque étape aide à identifier où la protection est nécessaire.
Infiltration : comment les attaquants obtiennent l'accès
Les attaquants compromettent directement les sites web en exploitant des vulnérabilités dans les systèmes de gestion de contenu ou les plateformes d'e-commerce. Cela leur donne accès pour modifier le code du site sans déclencher d'alertes côté serveur.
Les attaques de la chaîne d'approvisionnement ciblent les services tiers plutôt que votre site directement. Lorsque vous chargez des ressources depuis un fournisseur d'analytique compromis, un fournisseur de chatbot ou une bibliothèque de paiement, du code malveillant s'exécute aux côtés des fonctionnalités légitimes. Une seule violation chez un fournisseur tiers peut compromettre des milliers de sites en aval.
Implantation : comment le code de skimming est installé
Une fois que les attaquants ont l'accès, ils injectent du code de skimming à l'aide de plusieurs techniques. L'injection JavaScript insère du code malveillant qui opère aux côtés du traitement des paiements légitime. Le clonage de champs de formulaire crée des doublons invisibles qui capturent les données à mesure que les clients les saisissent.
Les attaques avancées remplacent des formulaires de paiement entiers par des versions frauduleuses visuellement identiques. Pour éviter la détection, les attaquants obfusquent leur code à l'aide de l'encodage Base64, de la fragmentation du code et de noms de domaine d'apparence légitime comme « google-analytics.net » au lieu de « google-analytics.com ».
Exfiltration : comment les données volées quittent le navigateur
Les données de paiement capturées sont transmises vers des serveurs contrôlés par les attaquants par transmission directe ou exfiltration furtive. Certains skimmers stockent les données collectées dans le stockage du navigateur et les transmettent par petits lots ou lorsque l'utilisateur quitte la page. Cela rend la détection plus difficile car le transfert de données ne se produit pas pendant le processus de paiement lui-même.
Qu'est-ce que la protection contre le vol de données ?
La protection contre le vol de données désigne les contrôles de sécurité qui surveillent, détectent et bloquent le comportement non autorisé des scripts dans le navigateur de vos visiteurs. Contrairement à la sécurité côté serveur qui s'arrête à la frontière du réseau, la protection côté client observe ce que les scripts font réellement à mesure qu'ils s'exécutent.
Une protection efficace contre le vol de données comprend la gestion de l'inventaire des scripts, la surveillance du comportement en temps réel, la détection des changements et des capacités d'application. cside collecte plus de 250 signaux de navigateur et d'appareil, surveille chaque charge utile de script tiers dans de vraies sessions de visiteurs et alerte votre équipe lorsque des scripts tentent d'accéder aux champs de formulaire de paiement ou d'exfiltrer des données vers des points de terminaison externes.
Pourquoi les outils de sécurité traditionnels passent à côté du vol de données
Les WAF inspectent le trafic à la frontière du serveur. Ils ne peuvent pas voir le JavaScript qui s'exécute côté client, les données qui quittent le navigateur via des appels de scripts tiers, ou les attaques ciblant des segments d'utilisateurs spécifiques selon la géographie ou la valeur du panier.
Les politiques de sécurité du contenu (CSP) restreignent les domaines qui peuvent charger des scripts mais ne peuvent pas surveiller le comportement des scripts une fois chargés. Si un fournisseur de confiance est compromis, le code malveillant s'exécute depuis un domaine approuvé. La CSP ne voit rien d'anormal car la source reste sur la liste d'autorisation.
Pourquoi les sites e-commerce ont besoin d'une protection contre le vol de données
Les pages de paiement e-commerce modernes chargent des dizaines de scripts tiers pour l'analytique, le marketing, les chatbots et le traitement des paiements. Les données de HTTP Archive montrent que le site web moyen utilise 23 scripts tiers, et chacun représente un point d'entrée potentiel pour les attaquants.
British Airways a subi une attaque Magecart qui a compromis les données de paiement de 380 000 clients, entraînant une amende de 20 millions de livres sterling au titre du RGPD. Ticketmaster a été victime d'une violation via un service de chatbot tiers compromis, affectant plus de 800 sites e-commerce utilisant le même fournisseur. Ces attaques sont restées indétectées pendant des semaines ou des mois pendant que les données de carte affluaient vers les attaquants.
Exigences de PCI DSS 4.0.1 pour la sécurité des pages de paiement
Les exigences 6.4.3 et 11.6.1 de PCI DSS 4.0.1 sont devenues obligatoires le 2025-03-31. L'exigence 6.4.3 impose aux organisations de maintenir un inventaire complet et autorisé de tous les scripts présents sur les pages de paiement et de documenter l'objectif et l'intégrité de chaque script.
L'exigence 11.6.1 impose des mécanismes de détection des changements et des altérations pour alerter le personnel en cas de modification non autorisée des scripts des pages de paiement. cside satisfait les deux exigences automatiquement : il inventorie chaque script dans de vraies sessions de visiteurs, génère des justifications rédigées par IA pour chaque script, surveille les en-têtes en temps réel et produit des rapports prêts pour l'audit acceptés par les QSA. VikingCloud a validé cside pour ces exigences.
Comment déployer une protection contre le vol de données
Le déploiement d'une protection contre le vol de données commence par l'obtention d'une visibilité sur les scripts qui s'exécutent actuellement sur vos pages de paiement. Vous ne pouvez pas protéger ce que vous ne pouvez pas voir.
Étape 1 : créer un inventaire des scripts
Documentez chaque script tiers s'exécutant sur vos pages de paiement. Pour chaque script, enregistrez son objectif, les données auxquelles il peut accéder et les pratiques de sécurité du fournisseur. Cet inventaire constitue la base de référence pour détecter les changements non autorisés.
Étape 2 : déployer une surveillance côté client
Ajoutez un script de surveillance léger à vos pages. cside se déploie via un unique extrait de code JavaScript ajouté à l'en-tête de votre page. Aucun trafic ne transite par l'infrastructure de cside, il n'y a pas de proxy inverse, aucune dépendance à un CDN et aucune modification de configuration DNS requise. L'extrait s'exécute directement dans le navigateur de vos visiteurs.
Étape 3 : configurer les alertes et l'application
Configurez des alertes pour les changements de scripts non autorisés, les ajouts de nouveaux scripts et les transmissions de données suspectes depuis les pages de paiement. Les attaques Magecart modifient des scripts de confiance existants ou en injectent de nouveaux. Les alertes en temps réel garantissent que votre équipe est informée des changements en quelques secondes, et non après un rapport de violation.
Limites des approches de protection courantes
Comprendre ce que chaque méthode de protection ne peut pas faire vous aide à construire une défense en couches.
Limites d'une protection reposant uniquement sur la CSP
La CSP contrôle quels scripts peuvent se charger mais pas ce qu'ils font après le chargement. Un script de fournisseur compromis s'exécute depuis un domaine approuvé. La CSP peine aussi avec les scripts dynamiques et le code en ligne généré à l'exécution.
Limites des solutions basées sur des scanners
Les scanners vérifient votre site périodiquement, souvent quotidiennement ou hebdomadairement. Les attaques ciblant des sessions d'utilisateurs spécifiques (commandes à forte valeur, certaines zones géographiques) échappent à la détection car le scanner voit une page propre. Les scanners ne peuvent pas non plus bloquer les attaques en cours puisqu'ils détectent les menaces après coup.
Limites de la journalisation côté serveur
Les journaux serveur enregistrent les requêtes entrantes et les réponses sortantes. Le vol de données se produit entièrement côté client. Les données de carte volées vont directement du navigateur du client au serveur de l'attaquant sans toucher votre infrastructure. Vos journaux affichent une transaction de paiement normale pendant que la violation se produit.
En conclusion : comment la protection contre le vol de données sécurise les paiements e-commerce
La protection contre le vol de données surveille les scripts exécutés par le navigateur pour détecter et bloquer le vol de paiement. Ces attaques exploitent l'écart entre la sécurité côté serveur et l'exécution du code côté client, opérant dans le seul endroit que vos outils existants ne peuvent pas voir.
cside offre à votre équipe une visibilité complète sur le comportement des scripts tiers sur les pages de paiement. Ajoutez un script léger à votre site web pour commencer à surveiller les scripts, détecter les attaques Magecart et générer immédiatement des preuves de conformité PCI DSS 4.0.1. Pour démarrer avec cside, réservez une démo.
