La principale menace qui pèse aujourd'hui sur les données de carte de crédit n'est pas un skimmer physique : ce sont les attaques sur la chaîne d'approvisionnement des sites web. Les attaquants insèrent du JavaScript malveillant dans les pages de paiement. Une fois injecté, ce script est conçu pour capturer les données de carte en temps réel au moment de leur saisie, souvent sans être détecté.
Le terme Magecart est souvent utilisé comme synonyme de ce type d'attaques. Il tire son origine des attaques survenues sur la plateforme Magento, très répandue dans le commerce en ligne. Il est formé de la combinaison de « Magento » et de « Cart » (panier), en référence aux paniers d'achat où ces attaques se produisent fréquemment.
Magento et WordPress sont tous deux des cibles privilégiées pour les attaques côté client. Ces attaques visent souvent des versions plus anciennes des plateformes qui n'ont pas été correctement mises à jour. Découvrez les plus grandes attaques Magecart de l'histoire à ce jour.
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. Le rapport indique que le système de perturbation des menaces eCommerce de Visa (eTD) analyse de manière proactive les sites marchands à la recherche de signatures de skimmers en Amérique du Nord et en Europe.
Le guide Digital Skimming: How to Stay Protected de Mastercard explique comment leur plateforme RiskRecon localise ces scripts malveillants, suit leurs dates et durées d'injection, et identifie les vulnérabilités associées.
Lire le rapport de Mastercard.
Comment fonctionne le skimming par chaîne d'approvisionnement
L'attaquant doit avoir accès à un fichier JavaScript présent sur la page ciblée. La façon d'y parvenir peut varier. L'approche la plus courante consiste à prendre le contrôle d'un script déjà présent sur le site. Il s'agit souvent d'anciens plugins qui n'ont pas été mis à jour ou maintenus, ou d'un script tiers ou d'un outil marketing qui a été compromis. L'attaquant modifie ensuite le script pour mener son attaque.
Il existe des variantes de cette méthode, comme on l'a vu lors de l'attaque contre Baways (British Airways). Dans ce cas, un attaquant a réussi à pénétrer dans le backend et à installer directement un script sur le site de BA.
Dans les deux cas, le script s'exécutant côté client (c'est-à-dire dans le navigateur) peut désormais effectuer toutes sortes d'opérations. Dans les opérations de skimming, ils procèdent le plus souvent ainsi :
- Copier simplement les champs du formulaire lors de la soumission ou par keylogging
- Rediriger la page de paiement vers un faux portail de paiement
- Superposer un iFrame malveillant sur la page de paiement d'origine
- …
Quiconque a accès au JavaScript d'une page peut virtuellement faire ce qu'il veut. Ces scripts sont très adaptables, dynamiques selon différents critères, et constituent le moyen silencieux idéal pour skimmer des cartes de crédit et des données personnelles (PII).
Vue d'ensemble des solutions
Basées sur un proxy
Le skimming côté client est difficile à détecter précisément parce qu'il se produit en dehors de votre infrastructure. Les scripts qui s'exécutent dans le navigateur de vos clients sont dynamiques, et les attaquants compromettent souvent des outils qui disposent déjà d'un accès légitime.
C'est pourquoi voir la charge utile réelle telle qu'elle est délivrée aux vrais utilisateurs est essentiel. Sans cette visibilité, vous n'êtes jamais totalement certain de ce qui s'est exécuté ni de l'origine de la compromission.
Nous avons construit notre solution autour d'un modèle de proxy hybride, car c'est la seule approche qui offre une couverture complète et en temps réel sur les frontends modernes. Chaque script qui atteint vos utilisateurs passe par le proxy. Notre solution de sécurité de la chaîne d'approvisionnement permet une visibilité totale sur la charge utile réellement délivrée, ainsi qu'un historique complet et une analyse des scripts.
Surveillance basée sur JavaScript (Agents)
Certains fournisseurs proposent une détection via des balises JavaScript que vous intégrez dans votre page. Cela signifie que l'attaquant les voit aussi. Pensez-y comme à un piège à souris : il peut être repéré et contourné. Si quelqu'un injecte des scripts dans votre page de paiement, il peut également modifier ou désactiver le script de protection/surveillance.
Les outils de détection seule ont également tendance à déclencher des alertes après que les données ont déjà été exfiltrées. Nous pensons que la prévention est préférable.
Crawlers
Les outils basés sur des crawlers fonctionnent en simulant des visites sur votre site et en capturant les scripts et ressources qui se chargent lors de cette visite. Mais ils n'obtiennent pas nécessairement la même charge utile de script qu'un utilisateur réel. Ils « imitent » un utilisateur.
Les scripts sont dynamiques par nature et les attaquants en tirent parti. En théorie comme en pratique, ces crawlers sont détectables et donc contournables.
Les crawlers sont utiles pour des analyses de surface. Mais les skimmers n'opèrent pas en surface.
Content Security Policy (CSP)
La Content Security Policy (CSP) est une fonctionnalité du navigateur qui permet aux propriétaires de sites de définir quelles sources de contenu (comme les scripts) sont autorisées à se charger sur une page. Correctement configurée, la CSP peut aider à bloquer du code tiers non autorisé ou inattendu en restreignant les origines des scripts.
C'est un contrôle préventif précieux, notamment pour réduire l'exposition aux injections de scripts inline ou au chargement depuis des domaines inconnus. Nous recommandons d'utiliser la CSP comme une couche parmi d'autres uniquement. Car la CSP ne peut pas voir la charge utile du script.
Dans nos conférences et présentations, nous utilisons souvent la diapositive suivante pour illustrer la CSP :
Vous avez 2 boîtes. L'une contient un chiot, l'autre une bombe. Laquelle est laquelle… ? C'est ça, la CSP.
En savoir plus sur la CSP ici.
Sur notre page de comparaison, nous détaillons les 4 approches présentées ici.
Récapitulatif des solutions
Les scripts qui se chargent dans le navigateur de vos clients peuvent accéder aux champs de saisie, modifier le contenu, envoyer des données ailleurs, et bien plus encore. Ils sont dynamiques, souvent issus de tiers, et peuvent être modifiés à votre insu.
C'est pourquoi le skimming côté client est si efficace. Et c'est pourquoi le prévenir nécessite bien plus qu'une simple analyse de surface.
Pourquoi le chemin de livraison est-il si important ?
Parce que c'est le seul moyen de voir ce qui atteint réellement l'utilisateur. Les scripts sont dynamiques. Les attaquants peuvent les modifier à tout moment, souvent de manière conditionnelle. Si vous n'êtes pas dans le chemin de livraison, vous vous appuyez sur des instantanés ou des suppositions. Se placer dans ce chemin signifie que vous voyez chaque requête, pour chaque session, en temps réel, et que vous pouvez agir avant que quoi que ce soit de dangereux ne s'exécute.
Quelle est la meilleure façon de prévenir ces attaques ?
La méthode la plus efficace aujourd'hui est notre surveillance des scripts basée sur un proxy. Elle inspecte chaque script avant qu'il n'atteigne le navigateur, vérifie son intégrité et bloque le code malveillant en temps réel. Elle fonctionne sur chaque session utilisateur et offre une visibilité complète, une journalisation et une couverture de conformité.
La surveillance basée sur JavaScript (Agents) est-elle une bonne option ?
Elle peut aider à détecter certaines menaces, mais elle s'exécute dans le même environnement que celui que les attaquants ciblent. Si un attaquant peut injecter un skimmer, il peut probablement aussi désactiver ou contourner le script de surveillance. C'est utile, mais insuffisant seul.
Un crawler est-il une bonne option ?
Les crawlers simulent des visites sur votre site et enregistrent les scripts visibles. Ils sont utiles pour des analyses périodiques, mais ils n'opèrent pas à l'intérieur de sessions réelles. Si un skimmer n'est actif que sous certaines conditions (comme un utilisateur connecté ou une plage d'adresses IP spécifique), les crawlers ne le verront pas.
La CSP est-elle une bonne option ?
La CSP (Content Security Policy) peut réduire les risques en limitant les origines depuis lesquelles les scripts sont autorisés à se charger. Mais elle n'analyse pas ce qu'un script fait une fois chargé. C'est une couche utile, mais pas un système de détection ni de prévention fiable à lui seul.
