En bref
- Le skimming de carte en ligne est un JavaScript malveillant sur la page de paiement d'un marchand qui copie les données de carte de paiement au fur et à mesure que le client les saisit.
- Les attaquants placent le script en compromettant un plugin tiers, une bibliothèque d'analytique ou un gestionnaire de balises que le site charge déjà.
- Les données volées quittent le navigateur directement vers un serveur contrôlé par l'attaquant. Votre backend, votre WAF et votre processeur de paiement ne les voient jamais.
- Le Rapport Semestriel sur les Menaces du Printemps 2025 de Visa identifie le skimming numérique comme "l'une des menaces les plus prolifiques et les plus constantes" de l'écosystème des paiements.
- Les exigences PCI DSS 4.0.1 6.4.3 et 11.6.1, obligatoires depuis le 31 mars 2025, existent spécifiquement pour contrer ce type d'attaque.
Qu'est-ce que le skimming de carte en ligne ?
- Skimming de carte en ligne
- Le skimming de carte en ligne est une cyberattaque dans laquelle un JavaScript malveillant s'exécute dans le navigateur d'un acheteur sur la page de paiement d'un marchand. Lorsque l'utilisateur saisit son numéro de carte, sa date d'expiration, son CVV et son adresse de facturation dans le formulaire de paiement, le script copie ces données et les transmet à un serveur contrôlé par l'attaquant, avant que le paiement ne soit soumis.
Le terme "skimming de carte" tire son origine de la fraude physique : un dispositif matériel fixé à un distributeur automatique ou à un terminal de point de vente qui lit la bande magnétique de la carte et enregistre le PIN lorsqu'un client le saisit. Le skimming de carte en ligne fonctionne sur le même principe mais ne nécessite aucun dispositif physique. Quelques lignes de JavaScript remplacent le matériel. L'attaque ne laisse aucune trace physique, peut s'exécuter indétectée pendant des mois et peut être déployée sur des milliers de sites simultanément via un seul script tiers compromis.
Le Rapport Semestriel sur les Menaces du Printemps 2025 de Visa a identifié le skimming numérique comme l'une des "menaces les plus prolifiques et les plus constantes" de l'écosystème des paiements, notant que le programme de Perturbation des Menaces e-Commerce de la société scanne activement les sites marchands à la recherche de signatures de skimmers en Amérique du Nord et en Europe.
Pour une vision complémentaire du côté exécution dans le navigateur de cette attaque, consultez notre guide détaillé sur l'e-skimming.
Comment les attaquants déploient-ils des scripts de skimming de cartes
Les attaquants ont besoin d'exécution de code sur la page de paiement cible. Ils l'obtiennent via des points d'entrée dans la chaîne d'approvisionnement plutôt qu'en attaquant directement le serveur du marchand :
- Un plugin tiers, une extension de CMS ou un widget compromis que le site du marchand charge déjà
- Une mise à jour malveillante poussée vers une bibliothèque d'analytique ou de gestionnaire de balises hébergée sur CDN
- Une violation du panneau d'administration du CMS ou du référentiel de code du marchand
Une fois qu'ils contrôlent un fichier JavaScript qui s'exécute sur la page de paiement, ils ajoutent la charge utile de skimming. Le script s'accroche aux champs du formulaire de paiement. Lorsque le client saisit, le script copie chaque valeur, encode les données et les envoie via HTTPS vers un domaine contrôlé par l'attaquant, typiquement un domaine similaire avec typosquatting conçu pour se fondre dans les journaux de trafic réseau. La demande d'exfiltration ne passe jamais par le serveur du marchand.
Trois propriétés rendent cela presque invisible depuis l'extérieur du navigateur : la demande sortante est chiffrée ; le domaine de destination imite un fournisseur légitime ; et la charge utile est suffisamment petite pour ressembler à un trafic d'analytique routinier.
Pourquoi les scanners de code au repos ne le détectent pas
La plupart des outils de sécurité web récupèrent une page, analysent le code source HTML et JavaScript, et signalent les signatures malveillantes connues. Le skimming de carte en ligne échappe à cette approche pour une raison structurelle : le skimmer s'exécute dans le vrai navigateur d'un utilisateur, où l'attaquant peut appliquer une logique conditionnelle qu'un scanner ne déclenche jamais.
Un script peut renvoyer du code propre aux robots d'exploration sans interface graphique et s'activer uniquement lorsqu'il détecte un comportement humain, une vraie adresse IP ou une région géographique spécifique. Le WAF, le serveur d'origine et le processeur de paiement du marchand ne reçoivent jamais aucune preuve du vol. Seule une couche de surveillance qui s'exécute dans de vraies sessions de visiteurs peut observer le script tel qu'il se comporte réellement.
Attaques de skimming de cartes en ligne connues
British Airways (2018). Des attaquants ont planté 22 lignes de JavaScript sur ba.com qui exfiltraient des données de paiement vers un domaine similaire, baways[.]com. Le script a fonctionné indétecté pendant environ deux mois et a touché environ 500 000 clients et membres du personnel. Le Bureau du Commissaire à l'Information du Royaume-Uni a émis une amende initiale de £183 millions en vertu du RGPD, finalement réduite à £20 millions. L'affaire a été l'une des premières actions d'application du RGPD liées directement à un échec de sécurité des paiements côté client.
Magecart (en cours). Le nom est originaire d'attaques ciblant les paniers d'achat basés sur Magento, mais il couvre maintenant des dizaines de groupes d'acteurs de menace distincts utilisant le skimming de cartes en ligne sur de nombreuses plateformes. Les acteurs Magecart ont compromis des fournisseurs de scripts tiers dont les bibliothèques s'exécutent simultanément sur des milliers de sites marchands, transformant une seule violation de la chaîne d'approvisionnement en un événement de vol de cartes massif. Voir les plus grandes attaques Magecart jamais enregistrées.
Exigences PCI DSS 4.0.1 pour la prévention du skimming de cartes
PCI DSS 4.0.1 a introduit deux exigences qui traitent directement le skimming de cartes en ligne. Les deux sont devenues obligatoires le 31 mars 2025 :
L'exigence 6.4.3 impose que chaque script chargé sur une page de paiement soit documenté dans un inventaire, autorisé avec une justification commerciale et que son intégrité soit protégée. L'intention est d'empêcher l'exécution de scripts non autorisés là où les données de carte sont saisies.
L'exigence 11.6.1 impose un mécanisme de détection de falsification qui alerte sur les modifications non autorisées des scripts de pages de paiement et des en-têtes HTTP affectant la sécurité, évalué au moins hebdomadairement ou selon un calendrier analysé par risque.
Les audits manuels de scripts et les analyses ponctuelles ne peuvent pas satisfaire ces exigences au volume et à la fréquence qu'elles spécifient. Une surveillance automatisée et continue de ce que les scripts font réellement dans de vrais navigateurs est la référence que les deux exigences sont rédigées pour imposer.
| Exigence | Ce qu'elle impose | Obligatoire depuis |
|---|---|---|
| 6.4.3 | Inventaire des scripts, autorisation et intégrité sur les pages de paiement | 31 mars 2025 |
| 11.6.1 | Détection de falsification avec alertes pour les changements sur les pages de paiement | 31 mars 2025 |
Comment détecter le skimming de cartes en ligne
La détection nécessite une visibilité sur ce que les scripts font dans les vrais navigateurs des visiteurs, pas seulement sur l'apparence de leur code source au moment du scan. cside déploie un seul extrait JavaScript propriétaire (sans proxy, sans modification DNS) qui surveille le comportement des scripts au niveau du navigateur à chaque chargement de page réel.
Les signaux que cside détecte pour la détection du skimming de cartes en ligne :
- Scripts nouveaux ou modifiés apparaissant sur les pages de paiement sans autorisation
- Écouteurs inattendus sur les champs de saisie gérant les données de carte
- Demandes sortantes vers des domaines hors d'une liste d'autorisation approuvée
- Comportement de script différant entre les sessions automatisées et les sessions d'utilisateurs réels
Cela produit l'enregistrement continu en temps réel que PCI DSS 4.0.1 exige : un inventaire de scripts autorisés pour le 6.4.3 et des preuves de détection de falsification pour le 11.6.1.
Lecture connexe :
