Attaque skimmer PrestaShop : vol de carte bancaire, causes & protection (guide)

Il y a des failles qui cassent un site. Et puis il y a celles qui le laissent tourner… pendant qu’on te vole en silence.

Le “digital skimmer” appartient clairement à la deuxième catégorie.

PrestaShop a récemment alerté certaines boutiques : un script malveillant a été détecté, capable de détourner l’étape de paiement et de voler des informations de carte bancaire. Ce n’est pas un bug. Ce n’est pas une “erreur de configuration”. C’est une attaque pensée pour être discrète, changeante, difficile à repérer et rentable.

Et le plus dangereux, c’est que tout peut paraître normal : le site fonctionne, les commandes tombent, le checkout s’affiche… mais une partie des clients peut, en parallèle, saisir ses données sur un faux formulaire ou cliquer sur un faux bouton de paiement.

Ce qu’est un “digital skimmer” (sans jargon)

Un skimmer, c’est une attaque qui vise un objectif très précis : récupérer les données de paiement au moment exact où l’utilisateur pense payer.

L’attaquant ne cherche pas à pirater une banque. Il cherche à pirater l’interface de paiement de ta boutique : le checkout, les boutons, le formulaire, le parcours.

Dans la pratique, le script injecté va soit remplacer les boutons de paiement (PayPal, CB, Stripe…) par des boutons frauduleux, soit superposer un faux formulaire, soit écouter les champs du paiement (numéro, date, CVV) avant l’envoi vers le vrai prestataire.

C’est exactement pour ça que cette attaque fait mal : elle ne casse rien, elle détourne. Et plus elle dure, plus elle rapporte.

Pourquoi le fichier `head.tpl` est souvent la cible

Dans l’alerte PrestaShop, un point revient : le skimmer est parfois injecté via un simple <script> dans le fichier themes/TON_THEME/templates/_partials/head.tpl.

Ce n’est pas un hasard. Le “head” est chargé partout : sur la home, sur les catégories, sur les produits, et surtout sur le checkout. Modifier un seul fichier peut suffire à contaminer l’expérience entière.

Et comme c’est un endroit “normal” pour mettre des scripts (analytics, pixels, tags…), une injection peut passer inaperçue si personne ne vérifie l’intégrité du thème.

Le détail technique qui trahit souvent le skimmer : `atob(...)`

Dans l’exemple partagé, le code utilise atob(...). C’est une fonction JavaScript qui décode une chaîne encodée en base64.

Pourquoi faire ça ? Parce qu’un attaquant ne veut pas écrire une URL “en clair” dans ton thème. Il veut éviter les détections simples, et il veut pouvoir faire tourner les domaines/chemins régulièrement.

En clair : ton fichier de thème contient un petit “chargeur” discret, et le vrai malware est récupéré à distance, changeant d’apparence d’une boutique à l’autre. C’est la logique du caméléon : même structure, signatures différentes.

La vraie question : comment ce script a pu être ajouté ?

Pour injecter un script dans head.tpl, il faut une chose : la capacité de modifier des fichiers sur le serveur. Donc, derrière le skimmer, il y a toujours une porte d’entrée.

Dans la majorité des cas, cette porte d’entrée ressemble à l’un de ces scénarios :

Un compte back-office compromis : mot de passe faible, réutilisé, phishing, session volée.
Un accès FTP/SFTP ou panel d’hébergement compromis : identifiants récupérés, poste infecté, fuite d’accès.
Une vulnérabilité dans un module : upload de fichier, exécution de code, faille non patchée, module non maintenu.
Un thème/module douteux : “nulled”, source non officielle, code déjà contaminé.
Des permissions serveur trop permissives : droits d’écriture trop larges, environnement mutualisé mal isolé.

Et c’est ça le piège : si tu supprimes juste le script, mais que la porte d’entrée est toujours ouverte, le skimmer revient. Parfois le lendemain. Parfois la semaine suivante.

Ce que je recommande de vérifier (pragmatique, sans dramatiser)

Si tu gères une boutique PrestaShop, voici une approche simple : vérifier vite, puis sécuriser proprement.

Commence par regarder dans ton thème : _partials/head.tpl, mais aussi header.tpl et les templates checkout. Cherche des patterns comme atob(, Function(, XMLHttpRequest, fetch vers des domaines inconnus, ou des scripts qui n’ont aucune raison d’être là.

Ensuite, ne te limite pas au “thème” : dans beaucoup d’incidents, l’injection est symptomatique d’un problème plus large. Il faut aussi contrôler les modules récents, les fichiers PHP ajoutés dans des dossiers inhabituels, et les comptes admin.

Et surtout : dès que tu confirmes une modification suspecte, change les accès. Back-office, FTP/SFTP, panel, base de données, clés API de paiement. Une compromission qui touche le paiement n’est jamais “petite”.

La règle d’or : la sécurité, c’est la confiance (et la confiance, c’est le business)

Un site e-commerce, ce n’est pas seulement un catalogue. C’est une chaîne de confiance : contenu, panier, paiement, livraison, service client.

Une attaque de type skimmer casse cette chaîne au pire endroit. Et le coût réel dépasse la technique : chargebacks, réputation, support, stress, et parfois obligations de notification selon le contexte.

La meilleure protection, ce n’est pas un “plugin miracle”. C’est une hygiène : mises à jour, modules maîtrisés, accès sécurisés, et contrôle régulier de l’intégrité du code.

Parce qu’en e-commerce, la sécurité n’est pas un sujet IT. C’est un sujet de croissance.

À retenir

Sécurité PrestaShop : comprendre le skimmer et protéger le paiement en ligne

Un skimmer PrestaShop est un malware e-commerce conçu pour voler les données de carte bancaire au moment du checkout. Il peut injecter un script dans le thème (souvent head.tpl) pour détourner les boutons de paiement, afficher un faux formulaire ou intercepter les champs. La bonne approche consiste à vérifier l’intégrité du thème, sécuriser les accès (back-office, FTP/SFTP, hébergement) et maintenir PrestaShop et ses modules à jour.

Malware e-commerce : pourquoi l’injection revient si on ne trouve pas la porte d’entrée

Supprimer un script suspect ne suffit pas toujours. Si l’attaque vient d’un module vulnérable, d’un compte admin compromis ou d’un accès serveur exposé, l’injection peut réapparaître. La prévention passe par un audit minimal : comptes admin, logs d’accès, modules installés, fichiers récents, permissions, et renouvellement des secrets (mots de passe et clés).

Mots-clés : sécurité PrestaShop, skimmer PrestaShop, digital skimmer, malware e-commerce, vol carte bancaire, paiement en ligne, Magecart, web skimming, head.tpl, thème PrestaShop, audit sécurité e-commerce, incident sécurité, RGPD, CNIL.