Le web skimming en 2026 : le guide complet du défenseur
Magecart, formjacking et skimmers dans les service workers forment une même famille de menaces. Voici à quoi ressemble le web skimming aujourd'hui et quel monitoring l'arrête vraiment.
Le web skimming est le terme générique désignant le vol de données de carte et d'identifiants directement depuis le navigateur du visiteur via du code côté client injecté. Magecart est le sous-groupe le plus connu, le formjacking est la technique plus large, et les skimmers sont les scripts eux-mêmes. Tous partagent le même modèle : une dépendance compromise, un listener silencieux, une exfiltration vers le domaine de l'attaquant.
Ce qui a changé en 2024–2026 : les skimmers se cachent rarement dans des balises <script> inline évidentes. Les variantes dominantes que nous observons se dissimulent dans les service workers (qui survivent aux rechargements de page), dans les blobs WebAssembly, dans les chunks chargés à la demande et dans la stéganographie PNG/SVG. Beaucoup se déclenchent de manière conditionnelle — uniquement pour des sessions réelles qui passent la vérification anti-analyse de détection de navigateur headless.
Cette conditionnalité explique pourquoi les scanners passifs échouent. Un scanner qui lit le HTML de façon statique ou effectue une correspondance de signatures une fois par jour ne voit pas un payload qui n'apparaît que lors d'une interaction réelle. Un monitoring d'exécution dans un vrai navigateur est nécessaire — un navigateur qui ressemble suffisamment à un vrai visiteur pour déclencher le skimmer, et qui enregistre tout quand il se déclenche.
L'approche d'ExploitShield : un Chromium entièrement instrumenté avec des hooks de service worker exécute un checkout synthétique toutes les 5 minutes, enregistre chaque corps JS exécuté, déobfusque les packers courants et compare chaque destination POST sortante à 500+ listes de blocage et à des heuristiques de points d'exfiltration en forme de skimmer. Le skimmer se déclenche exactement une fois par session d'apparence réelle — et nous le voyons, parce que nous ressemblons à une session réelle.
Liste de contrôle pour le défenseur : maintenez un inventaire des scripts tiers sur les parcours de paiement ; appliquez une Content-Security-Policy avec une liste d'autorisation des connexions ; surveillez les destinations sortantes lors d'une exécution réelle ; et traitez tout domaine nouvellement enregistré atteint depuis une page de paiement comme un incident jusqu'à preuve du contraire.