Skimmer JavaScript sur WooCommerce : le checkout a l'air normal

Ce qu'un skimmer WooCommerce fait vraiment

Magecart, pour le dire simplement : un JavaScript chargé sur le checkout écoute les champs (numéro, date, CVC, parfois nom et adresse) et les envoie vers un domaine qui n'est pas Stripe, PayPal ou votre banque. Le paiement peut ensuite se dérouler « pour de vrai » : le client est débité, la commande se crée, personne ne se plaint tout de suite. D'autres variantes redirigent vers une fausse page carte. Les deux se traitent comme un incident paiement, pas comme un défacement.

WooCommerce ne stocke en principe pas le PAN complet si vous êtes en redirection ou en champs hébergés (Stripe Elements, etc.). Un skimmer n'a pas besoin de votre table : il lit le DOM. « On ne stocke pas les cartes » n'est donc pas un argument. Le HTML servi au navigateur l'est, ou ne l'est pas.

La fenêtre de dates commence au premier HTML sale que vous pouvez prouver (Search Console, cache, témoignage client) et finit à la coupure du script + invalidation des caches. Cette fenêtre part chez le prestataire. Voir informer sa banque et PCI-DSS après un skimmer.

Tester le tunnel, pas la page d'accueil

Ajoutez un produit, allez jusqu'au paiement, en navigation privée, sur mobile, sans être admin. Enregistrez le HTML de `/checkout/` (et des étapes blocs WooCommerce). Cherchez des `<script>` dont le domaine n'est pas le vôtre, Stripe, PayPal, votre PSP, votre GTM habituel. Un `jquery` chargé depuis un TLD bizarre, un pixel inconnu, un WebSocket vers ailleurs : notez l'URL exacte.

L'inspecteur réseau (onglet Network) montre les POST au blur d'un champ. Faites le test avec une carte de test ou arrêtez-vous avant de valider si vous voyez déjà l'appel. Ne saisissez pas une vraie carte « pour voir ».

Search Console, inspection de l'URL checkout, peut montrer un HTML différent (cloaking). Gardez les deux HTML. Un écart est une preuve.

• Source de `/checkout/` déconnecté, mobile, privé.
• Liste des domaines JS chargés.
• Appels réseau au moment de la saisie (sans vraie carte).

Où le JavaScript se loge

Thème enfant (`woocommerce/checkout/*.php`, `functions.php` qui `wp_enqueue_script` une URL inconnue), plugin de paiement nulled ou abandonné, widget / `theme_mods` / insert headers, option de cache minifié, conteneur GTM que vous ne contrôlez plus, extension Chrome du prestataire — non, celle-là c'est vous. En base : voir JS dans wp_options. En fichiers : comparez le plugin Stripe / PayPal officiel au zip du compte développeur, pas à un « pack nulled ».

Un module « optimisation checkout » ou un overlay de réduction chargé uniquement sur le tunnel est un camouflage fréquent. Désactivez les extra JS du checkout le temps du triage, un par un, en retestant le HTML.

Les blocs checkout WooCommerce (Cart/Checkout blocks) chargent d'autres bundles. Un script injecté dans une option de thème blocks se voit dans le source compilé servi, pas forcément dans `footer.php`.

3-D Secure ne lit pas votre HTML

3-D Secure authentifie le porteur chez sa banque après coup, ou dans un iframe. Le skimmer a déjà lu les champs sur votre page, avant. Ce n'est pas un bouclier contre Magecart. Détail : le 3-D Secure n'empêche pas un skimmer. Ne l'invoquez pas auprès d'un client ou d'un assureur comme preuve qu'aucune carte n'a été vue.

Couper le checkout sans fermer la vitrine

Désactivez les moyens de paiement, ou l'étape commande, ou renvoyez vers une page « paiement temporairement indisponible ». La vitrine, le catalogue, le SEO restent. Fermer tout le site pour un skimmer coûte du référencement sans raccourcir l'analyse. Exception : le kit est un phishing plein écran — là, on coupe l'URL. Voir boutique fermée pendant le piratage et paiement redirigé.

Quelques heures sans encaisser valent mieux que des dizaines de cartes copiées un week-end de soldes. L'arbitrage Black Friday est le même, en plus cher : Black Friday et site piraté.

Webhooks, clés et journaux de paiement

Chez Stripe / PayPal / votre PSP : liste des webhooks (URL encore la vôtre ?), clés API (aucune que vous ne nommez pas), journaux d'événements sur la fenêtre. Un webhook tourné vers un tiers prévient l'attaquant des paiements réussis ; ce n'est pas le skimmer, c'est un second canal. Webhooks détournés.

Côté WooCommerce : clés REST, webhooks boutique, logs `woocommerce-` dans `wp-content/uploads`. Révoquez l'inconnu. Les journaux d'envoi mail (confirmations de commande) disent si un pic de commandes fantômes a eu lieu — utile pour la fenêtre, pas pour prouver l'absence de skimmer.

Prévenir prestataire et clients

Stripe, PayPal, banque : dates, URL de checkout, volume, HTML ou URL du script, constat. Le canal incident du prestataire, pas seulement le chat grand public. Stripe et site piraté, litiges PayPal.

Clients : fenêtre, de surveiller les relevés, ce qui a été fait, pas « aucune fuite » tant que l'analyse n'est pas close. La CNIL peut entrer. Textes utiles : cartes peut-être vues et fuite de données. La déclaration, si elle est due, vous incombe.

Nettoyer sans « vider WooCommerce »

On retire le script (fichier, option, plugin, GTM), on compare les modules de paiement à l'officiel, on garde commandes et catalogue. Réinstaller WooCommerce « à neuf » perd HPOS, taxes, traductions, et ne retire pas une option `theme_mods` ni un mu-plugin. Videz tous les caches (plugin, hébergeur, CDN) après, sinon le skimmer est encore servi. Cache LiteSpeed.

Refermez users, FTP, panel. Un checkout propre et un admin ouvert, et le JS est recollé avant le week-end.

Reprendre les commandes et les badges

Rouvrez le paiement après un test tunnel propre (privé, mobile, HTML relu). Remettez les mentions « paiement sécurisé » seulement à ce moment — mentions après incident. Surveillez 7 à 14 jours les chargebacks et les webhooks.

Pour un audit de checkout et un constat prestataire, créez un espace. Le prix s'affiche avant l'accès.

• HTML checkout sans script tiers inconnu.
• Paiement isolé le temps du doute, vitrine ouverte.
• Clés et webhooks PSP relus.
• Prestataire informé avec fenêtre de dates.