En bref : qu'est-ce que le formjacking
- Du JavaScript injecté sur un formulaire pour voler ce que les utilisateurs saisissent avant submit. Champs de carte, credentials ou PII.
- Il tourne dans le navigateur après le service de la page. Votre WAF et vos logs d'origine ne voient rien. Le script compromis se trouve dans un domaine autorisé de confiance.
- Voie conformité : inventaire de scripts 6.4.3 et détection d'altération 11.6.1. Voie technique : monitoring en session.
Comment fonctionne le formjacking
Une attaque de formjacking se déroule en quatre étapes.
Le diagramme suit un passage en caisse (shop.example[.]com/checkout) à travers cinq étapes, et montre pourquoi une vue au niveau réseau reste aveugle tandis qu'une vue au niveau navigateur le détecte :
| Étape | Ce qui se passe dans le navigateur | Ce que voit le serveur / la CSP |
|---|---|---|
| 1. Page de checkout | L'acheteur saisit le numéro de carte + le CVV dans le vrai formulaire | Chargement de page normal |
| 2. Script fournisseur falsifié | widget.js (modified) se charge comme n'importe quelle autre balise tierce | Une URL de script autorisée et déjà de confiance |
| 3. Skimmer de formulaire | L'écouteur injecté s'accroche à chaque champ de saisie et lit les frappes en temps réel | Rien, aucune requête vers le serveur |
| 4. Endpoint d'exfiltration | Copie encodée envoyée à cdn-metrics[.]example via POST /collect?d=eyJjYyI6…, déguisée en balise d'analyse | Ressemble à du trafic d'analyse ordinaire |
| 5. Attaquant | Cartes volées revendues ou utilisées pour de la fraude au carding ; le vrai paiement aboutit quand même | Aucune anomalie, la transaction réussit |
La couche réseau est aveugle parce que la requête d'exfiltration quitte le navigateur directement vers le domaine de l'attaquant. cside surveille la couche navigateur, si bien que l'écouteur injecté et la balise sortante sont détectés là où ils s'exécutent réellement.
1. Introduire du code dans la page. L'attaquant place du JavaScript sur la page cible, presque toujours à l'insu du propriétaire du site. La voie la plus courante consiste à compromettre un script tiers, une balise d'analyse, un widget de chat, un outil de test A/B ou une bibliothèque de paiement, de sorte que le skimmer arrive intégré dans du code auquel le site fait déjà confiance et qu'il charge à chaque passage en caisse.
2. S'accrocher aux champs de formulaire. Une fois le script chargé, il attache des écouteurs d'événements au formulaire de paiement ou de connexion. Un écouteur sur l'événement input se déclenche à chaque frappe ; un sur l'événement submit se déclenche lorsque l'utilisateur clique sur payer. Le script peut également lire directement les valeurs depuis le DOM une fois que les champs sont remplis.
3. Copier les données. L'écouteur capture les valeurs des champs, numéro de carte, expiration, CVV, adresse de facturation, exactement telles que l'utilisateur les a saisies. Le formulaire lui-même n'est pas modifié. La transaction de l'utilisateur passe toujours par le processeur de paiement légitime.
4. Exfiltrer. Les données volées sont encodées et envoyées vers un domaine contrôlé par l'attaquant, souvent déguisées en ping d'analyse ou en requête d'image pour se fondre dans le trafic sortant normal de la page. La plupart des en-têtes Content Security Policy ne bloquent pas cela parce que l'attaquant utilise soit un domaine déjà autorisé par la politique, soit exploite une lacune existante.
Comment les attaquants introduisent-ils du code de formjacking sur votre site
Le formjacking ne nécessite pas de violation directe de vos serveurs. Les trois voies de livraison les plus courantes :
Compromission de script tiers. La plupart des pages de paiement et d'e-commerce chargent entre 20 et 60 scripts tiers, plateformes d'analyse, outils de chat, gestionnaires de balises, bibliothèques de paiement, widgets de fournisseurs marketing. Chacun de ces fournisseurs représente une surface d'attaque. Si l'attaquant compromet l'infrastructure ou le CDN du fournisseur, chaque site chargeant ce script reçoit le skimmer. La violation de British Airways en 2018 a mis en danger les données personnelles de 429 612 clients après modification du JavaScript dans le flux de paiement de la compagnie aérienne. Des chercheurs ont lié l'attaque à des acteurs Magecart utilisant un script de fournisseur tiers compromis, et non une violation directe des serveurs de British Airways. (Wikipedia : Violation de données British Airways)
Domaines expirés ou détournés. Les sites chargent parfois des scripts depuis des domaines tiers qui ont depuis expiré ou changé de propriétaire. Un attaquant qui enregistre ce domaine peut alors servir n'importe quel JavaScript aux sites chargeant toujours l'ancienne balise de script. Comme l'URL n'a pas changé et que le domaine servait auparavant du code légitime, aucune vérification automatique ne l'identifie immédiatement.
Injection de code directe. Si l'attaquant exploite une vulnérabilité dans le CMS, le panneau d'administration ou un plugin du site, il peut injecter le script de formjacking directement dans les fichiers du site. Cette voie nécessite plus d'accès mais ne laisse aucune dépendance externe à tracer.
Ce que le formjacking cible
Les attaquants privilégient les pages qui collectent des données de grande valeur avec un minimum de friction :
| Type de page | Données généralement capturées |
|---|---|
| Paiement e-commerce | Numéro de carte, expiration, CVV, adresse de facturation |
| Inscription de compte | E-mail, mot de passe, nom, adresse postale |
| Pages de connexion | Nom d'utilisateur et mot de passe |
| Formulaires de santé | Numéro d'assurance, date de naissance, informations médicales |
| Demandes de compte financier | NIF, revenus, coordonnées bancaires |
Les pages de paiement sont la cible principale car les données de cartes ont un marché de revente immédiat. Les identifiants de connexion sont la deuxième priorité car ils permettent la prise de contrôle de comptes sur des plateformes avec des méthodes de paiement enregistrées.
Pourquoi les outils de sécurité traditionnels manquent le formjacking
Les pare-feux d'application web protègent le trafic atteignant votre serveur. Les données du formjacking quittent le navigateur directement vers un domaine de l'attaquant, le WAF ne les voit jamais.
Les scanners côté serveur inspectent le code au repos sur votre origine. Un script tiers compromis se charge depuis le CDN d'un fournisseur au moment de l'exécution, il n'est donc jamais sur votre serveur pour être analysé.
Les révisions manuelles périodiques vérifient les scripts listés dans votre gestionnaire de balises ou votre dépôt de code. Un skimmer injecté dans un script tiers entre les cycles de révision est invisible jusqu'à ce que quelqu'un effectue le prochain audit, souvent des semaines plus tard.
La Subresource Integrity (SRI) protège les scripts dont vous calculez le hash au moment du déploiement. Elle ne peut pas protéger les scripts chargés depuis des CDN contrôlés par des fournisseurs où l'attaquant a un accès en écriture, ni les scripts générés dynamiquement par requête.
Les exigences 6.4.3 et 11.6.1 de PCI DSS 4.0.1 existent parce que l'industrie a reconnu cette lacune. L'inventaire des scripts et la surveillance continue des altérations sur les pages de paiement sont devenus obligatoires le 1er avril 2025. (PCI Security Standards Council)
Les skimmers contournent aussi activement les scanners. La plupart vérifient navigator.webdriver, qui retourne true dans les navigateurs headless automatisés, et servent du code propre aux outils de sécurité tout en exécutant le skimmer complet pour les vrais utilisateurs.
Comment détecter le formjacking
Détecter le formjacking nécessite une visibilité sur ce que JavaScript fait au moment de l'exécution dans les navigateurs des vrais visiteurs. Les signaux spécifiques à surveiller :
- Scripts nouveaux ou modifiés sur les pages sensibles. Un script absent la veille, ou dont le contenu a changé en dehors d'une fenêtre de déploiement planifiée, est le premier indicateur.
- Écouteurs d'événements inattendus sur les champs de formulaire. Le code légitime attache des écouteurs
submitpour traiter les formulaires. Un écouteur sur les événementsinput,keydownoukeyupsur des champs de paiement ou d'identifiants, ajouté par un script tiers, est une signature caractéristique du formjacking. - Données sortantes vers des domaines non listés. Toute requête réseau depuis une page de paiement vers un domaine ne figurant pas sur votre liste autorisée approuvée justifie une investigation immédiate.
- Charges utiles encodées dans les requêtes sortantes. Les formjackers encodent les données volées, souvent en base64, avant de les envoyer. Une balise contenant un paramètre encodé inhabituellement long qui ne correspond à aucun événement d'analyse connu est un signal d'alarme.
La contrainte clé est que seule la surveillance à l'intérieur du navigateur peut voir ces signaux en conditions réelles. Les scanners opérant depuis l'extérieur manquent le formjacking qui se dissimule aux utilisateurs réels.
Comment prévenir le formjacking
Aucun contrôle unique n'élimine toutes les voies de formjacking. Combiner plusieurs contrôles réduit significativement la surface d'attaque :
-
Inventorier chaque script sur les pages sensibles. Connaître chaque script propriétaire et tiers chargé sur les pages de paiement et de connexion, qui l'a autorisé et pourquoi il est là. Les scripts non reconnus ne doivent pas se charger.
-
Surveiller les changements en continu. Un script qui change entre les cycles d'audit est une violation non détectée. La surveillance continue des altérations, obligatoire en vertu de l'exigence 11.6.1 de PCI DSS 4.0.1, détecte les changements en minutes plutôt qu'en semaines.
-
Appliquer la SRI là où c'est pratique. Pour les scripts que vous contrôlez totalement et versionnez vous-même, les hashes SRI vérifient que le script n'a pas changé depuis le déploiement. La SRI ne fonctionne pas pour les scripts tiers mis à jour fréquemment ou générés dynamiquement par requête.
-
Configurer la Content Security Policy de manière restrictive. Une CSP stricte limite les domaines vers lesquels les scripts peuvent envoyer des données, réduisant les destinations d'exfiltration d'un skimmer. En pratique, les pages de paiement ont souvent besoin d'autoriser de nombreux domaines pour l'analyse légitime et les fonctionnalités de paiement, ce qui rend un blocage complet difficile.
-
Déployer une surveillance client-side des vrais visiteurs. La défense la plus directe est une surveillance qui observe ce que chaque script fait dans de vrais navigateurs, non un scanner exécutant des requêtes synthétiques depuis l'extérieur. C'est l'approche de cside.
Comment cside détecte le formjacking dans les vrais navigateurs
cside se déploie sous la forme d'un unique snippet JavaScript propriétaire qui surveille le comportement des scripts dans les navigateurs des vrais visiteurs, pas un robot d'exploration ou un scanner opérant depuis l'extérieur.
Pour le formjacking, cside détecte :
- Les écouteurs d'événements attachés aux champs de formulaire par des scripts tiers, avec une attention particulière aux écouteurs qui se déclenchent sur les frappes plutôt que sur la soumission du formulaire
- Les requêtes de données sortantes vers des domaines ne figurant pas sur la liste autorisée approuvée du site
- Les nouveaux scripts apparaissant sur les pages de paiement ou de connexion en dehors d'une fenêtre de déploiement
- Les modifications de scripts existants, y compris les modifications au moment de l'exécution dans la sortie chargée d'une balise fournisseur
Comme cside opère au niveau du navigateur aux côtés de l'attaque, il détecte le skimmer au moment où il se déclenche, avant que les données n'aient déjà été exfiltrées. Pour les organisations soumises à PCI DSS 4.0.1, PCI Shield mappe cette surveillance aux exigences 6.4.3 (inventaire et autorisation des scripts) et 11.6.1 (détection des altérations), générant des rapports prêts pour le QSA en continu.
Pour le contexte sur la relation entre le formjacking et le vaste écosystème du skimming numérique et les groupes de menace Magecart, consultez le guide complémentaire : Formjacking vs Magecart vs skimming numérique.
Réservez une démo pour voir ce que cside trouve sur vos pages de paiement, ou en savoir plus sur la prévention du e-skimming.
