En bref : comment les skimmers basés sur les formulaires volent les données de carte
- Votre WAF et votre CSP vous diront que le checkout est propre pendant que les données de carte quittent le navigateur. Ces contrôles vivent au niveau réseau et le vol se produit dans le DOM, sur un script servi depuis un domaine que votre allowlist juge déjà de confiance.
- Visa attribue 70% du vol de cartes bancaires à la couche client, et British Airways a perdu environ 380 000 enregistrements en 22 jours avant de payer une amende de 20 millions de livres de l'ICO. cside hache chaque payload de script dans des sessions navigateur réelles et alerte dès qu'un hash change.
- Si vous ne pouvez pas dire si un script de domaine de confiance a été modifié dans la dernière heure, vous êtes à un échange de payload d'être la prochaine étude de cas.
Le formjacking est une attaque web qui injecte du JavaScript malveillant dans une page de paiement ou de commande pour voler les données de carte au moment où le visiteur les saisit. Le script lit les valeurs des champs du formulaire en temps réel, les envoie vers un serveur contrôlé par l'attaquant, et laisse la transaction d'origine se terminer normalement. L'acheteur reçoit une confirmation, le marchand voit une vente finalisée, et les détails de la carte ont déjà disparu. Comme le vol se produit à l'intérieur du navigateur, il reste invisible pour les contrôles au niveau du réseau et du serveur sur lesquels s'appuient la plupart des marchands.
Comment fonctionne le formjacking : étape par étape
Le formjacking est une attaque au niveau de l'exécution. Elle ne nécessite ni intrusion réseau ni compromission du serveur. Voici comment elle se déroule.
-
Un attaquant injecte du JavaScript malveillant dans une page de paiement ou de commande. Cela se fait généralement en compromettant un script tiers que le marchand charge déjà, comme un gestionnaire de balises (tag manager), une bibliothèque d'analytique ou un utilitaire hébergé sur un CDN.
-
Lorsqu'un visiteur atteint le formulaire de paiement, le script injecté commence à intercepter les frappes au clavier ou les valeurs des champs dans le Document Object Model du navigateur. Il n'a pas besoin d'attendre la soumission du formulaire.
-
Au fur et à mesure que le visiteur saisit son numéro de carte, sa date d'expiration et son CVV, le script capture ces valeurs et les exfiltre en temps réel vers un serveur contrôlé par l'attaquant. Le transfert est généralement encodé pour éviter une détection évidente au niveau du réseau.
-
Le formulaire d'origine continue de fonctionner. Le paiement est traité, le visiteur reçoit une confirmation, et rien dans son navigateur ni dans les journaux du serveur du marchand ne signale quoi que ce soit d'inhabituel.
C'est pourquoi le formjacking est si dangereux. Il n'y a aucune erreur, aucune transaction échouée et aucune anomalie au niveau du réseau ou du serveur. L'attaque est invisible pour les contrôles que la plupart des marchands ont en place.
British Airways 2018 : ce qui s'est passé
En 2018, un acteur malveillant Magecart a injecté un script de formjacking dans le site de réservation de British Airways et a opéré sans être détecté pendant 22 jours, compromettant environ 380 000 enregistrements de paiement de clients, dont des numéros de carte, des dates d'expiration, des CVV et des informations personnelles. Les systèmes internes ne l'ont pas détecté durant cette période car aucune surveillance au niveau de la charge utile n'était en place.
L'attaque a modifié un script déjà présent sur le site, de sorte qu'aucune nouvelle URL de script n'est apparue. Aucune règle de Content Security Policy ne s'est déclenchée, car le domaine servant le script modifié figurait déjà sur la liste d'autorisation.
L'enquête de l'ICO a abouti à une amende de 20 millions de livres sterling. La conclusion sur la cause racine a identifié l'incapacité à détecter un changement de charge utile à l'intérieur d'un script de confiance comme la défaillance technique centrale.
Visa rapporte qu'une large majorité des vols de cartes de paiement se produit désormais à la couche client, dans le navigateur, plutôt que sur le serveur ou en transit :
| Où les données de carte sont volées | Part des vols |
|---|---|
| Couche client (navigateur / DOM) | 70 % |
| Couche serveur / réseau | 30 % |
Source : Visa. Le formjacking est le principal mécanisme derrière ces 70 %.
Formjacking et Magecart : ce que signifie chaque terme
Magecart est une catégorie d'acteurs malveillants, pas une technique. Le nom désigne un collectif informel de groupes criminels qui utilisent le formjacking comme principale méthode d'attaque.
Le formjacking est la technique : injecter du JavaScript pour intercepter et exfiltrer les données de formulaire. Les groupes Magecart figurent parmi les utilisateurs les plus prolifiques de cette technique, mais ils ne sont pas les seuls.
Lorsque les chercheurs et les journalistes emploient ces termes de manière interchangeable, ils décrivent généralement une attaque de formjacking attribuée à Magecart. La distinction compte pour la détection. Vous ne recherchez pas la signature d'un groupe précis ; vous recherchez le comportement d'interception de la charge utile, quel qu'en soit l'auteur.
Pourquoi les WAF et les CSP n'arrêtent pas le formjacking
Un pare-feu applicatif web (WAF) inspecte le trafic HTTP au niveau du réseau. Il voit les requêtes et les réponses entre le navigateur et le serveur, mais il n'a aucune visibilité sur le JavaScript qui s'exécute dans le DOM après le chargement de la page. Un script de formjacking vit entièrement dans le DOM. Il ne génère pas de requête suspecte vers le serveur du marchand ; il envoie les données volées directement vers un point de terminaison contrôlé par l'attaquant.
Une Content Security Policy restreint les domaines autorisés à servir des scripts, et c'est un contrôle utile. Mais une attaque de formjacking modifie généralement un script servi depuis un domaine auquel la CSP fait déjà confiance. Le domaine passe le contrôle de la liste d'autorisation, et la charge utile elle-même n'est jamais inspectée. C'est le même angle mort que celui que pointe Visa lorsqu'il attribue environ 70 % des vols de cartes à la couche client, où les WAF et les contrôles côté serveur n'ont aucune visibilité.
Comment la surveillance des scripts de cside détecte le formjacking
La surveillance des scripts en session réelle détecte le formjacking en calculant le hash de chaque charge utile de script au moment où elle s'exécute dans un véritable environnement de navigateur, puis en alertant dès qu'un hash change. Cela permet de repérer l'injection de charge utile à l'intérieur de scripts de confiance, que la liste d'autorisation d'une CSP et un WAF laissent tous deux passer.
La surveillance des scripts cside s'exécute dans de véritables sessions de navigateur et combine plus de 100 signaux par session en un verdict en temps réel.
Lorsqu'une charge utile de formjacking est injectée dans un script de confiance, le hash de ce script change. cside détecte le changement en quasi temps réel et déclenche une alerte qui inclut l'identifiant du script, le hash précédent, le nouveau hash et un horodatage. L'alerte arrive avant que le script compromis ne puisse accumuler un volume significatif de données volées.
L'empreinte numérique (fingerprinting) de cside conserve une haute précision à travers les sessions en navigation privée, sous VPN et après effacement des cookies, et sa méthodologie de surveillance est validée par VikingCloud.
L'exigence PCI DSS qui cible spécifiquement le formjacking
Les exigences PCI DSS 6.4.3 et 11.6.1 ont été introduites spécifiquement pour traiter le risque de formjacking, et elles sont devenues obligatoires le 31 mars 2025.
L'exigence 6.4.3 demande aux marchands d'inventorier chaque script présent sur les pages de paiement, de documenter une justification métier pour chacun, d'obtenir une autorisation explicite et de vérifier l'intégrité en continu. Cela cible directement le scénario où un script de confiance est modifié à l'insu du marchand.
L'exigence 11.6.1 impose un mécanisme d'alerte qui se déclenche lorsque les en-têtes ou le contenu d'une page de paiement changent de manière non autorisée. La détection en quasi temps réel qu'offre cside atteint et dépasse ce que les QSA recherchent lorsqu'ils examinent les preuves relatives à 11.6.1.
Vérifiez le risque d'injection sur vos pages de paiement et commencez gratuitement avec cside PCI Shield. Pour comprendre comment ces termes sont liés, voyez formjacking vs Magecart vs digital skimming, et pour découvrir comment la surveillance continue fonctionne en pratique, voyez les meilleures plateformes de surveillance des scripts tiers.
