Boutique PrestaShop piratée : que faire en urgence (Magecart, skimmer)

Un piratage PrestaShop n’est pas comme un piratage WordPress. Quand un WordPress est compromis, l’attaquant cherche souvent à envoyer du spam, à faire du SEO Black Hat, ou à afficher des pages de phishing. C’est gênant, parfois sérieux, mais rarement catastrophique pour vos clients.

Quand un PrestaShop est compromis, il y a un risque bien plus grave : le vol de numéros de carte bancaire en temps réel, directement pendant que vos clients passent commande. C’est ce qu’on appelle une attaque Magecart ou un card skimmer. Et les conséquences légales et financières pour vous, en tant que commerçant, peuvent être dévastatrices.

Comment fonctionne un skimmer PrestaShop

L’attaquant injecte un petit morceau de JavaScript dans votre thème ou dans un module. Ce script est invisible pour l’utilisateur. Pendant que le client saisit son numéro de CB, le CVV et la date d’expiration, le script copie ces données et les envoie silencieusement vers un serveur contrôlé par l’attaquant — souvent un domaine qui ressemble à quelque chose de légitime, comme google-analytics.net ou jquery-cdn.com.

Résultat : votre boutique fonctionne parfaitement. Vos clients paient normalement. Rien ne cloche en apparence. Mais en arrière-plan, des milliers de données de paiement sont volées.

Signes qu’un skimmer est actif sur votre boutique

Signe 1 : des signalements clients Des clients vous contactent pour signaler des achats frauduleux sur leur carte bancaire après avoir commandé chez vous. C’est souvent le premier signal d’alarme, et il arrive malheureusement après des semaines de vol silencieux.

Signe 2 : un script JavaScript inconnu dans le thème En inspectant le code source de votre page de paiement (clic droit > Afficher le code source), vous repérez un fichier JS externe que vous ne reconnaissez pas — surtout s’il est chargé depuis un domaine tiers sans rapport avec vos outils habituels (Stripe, PayPal, Google Analytics…).

Signe 3 : des requêtes vers des domaines externes suspects En utilisant les outils développeur de votre navigateur (onglet Network), observez les requêtes réseau pendant le processus de paiement. Toute requête POST vers un domaine inconnu pendant la saisie de la carte est un signal critique.

Signe 4 : des fichiers modifiés récemment sans raison Si votre thème ou vos modules ont des fichiers dont la date de modification est récente sans que vous ayez rien changé, c’est suspect.

L’impact légal : RGPD et obligation de notification à la CNIL

En tant que responsable de traitement, vous êtes légalement tenu de notifier la CNIL dans les 72 heures suivant la découverte d’une violation de données personnelles (article 33 du RGPD). Les données de paiement sont des données sensibles : l’obligation est particulièrement stricte.

Ne pas notifier peut entraîner des sanctions financières importantes. La CNIL a déjà sanctionné des e-commerçants pour des violations de données non déclarées, indépendamment des dommages causés aux clients.

En parallèle, votre banque acquéreuse peut suspendre votre capacité à accepter des paiements CB si elle détecte un compromis sur votre boutique (procédure PCI-DSS). C’est une situation qui peut mettre en péril l’activité immédiatement.

La procédure d’urgence, étape par étape

Étape 1 : couper la boutique immédiatement

Mettez PrestaShop en mode maintenance depuis le back-office (si accessible) : Paramètres > Maintenance > Activer le mode maintenance. Si vous n’avez pas accès au back-office, créez un fichier maintenance.php ou bloquez l’accès via .htaccess.

Chaque minute supplémentaire d’activité = de nouvelles données de paiement volées.

Étape 2 : faire un dump complet de la base de données

Avant de toucher quoi que ce soit, sauvegardez la base de données via phpMyAdmin ou en SSH :

mysqldump -u user -p nom_de_la_base > backup_avant_nettoyage_$(date +%Y%m%d).sql

Cette sauvegarde servira de preuve si nécessaire et de point de restauration.

Étape 3 : scanner les fichiers modifiés récemment

Depuis la racine de votre installation PrestaShop en SSH :

find . -type f -newer ./index.php -name "*.php" -o -type f -newer ./index.php -name "*.js" | grep -v cache | grep -v var/

Cette commande liste tous les fichiers PHP et JS modifiés après votre fichier index.php de référence. Examinez chaque résultat : un fichier JS modifié dans votre thème sans raison légitime est un suspect direct.

Vérifiez aussi spécifiquement les fichiers de thème et les modules :

find ./themes -name "*.js" -newer ./index.php
find ./modules -name "*.php" -newer ./index.php

Étape 4 : identifier et supprimer le script malveillant

Une fois le fichier identifié, ouvrez-le et cherchez du code obfusqué : longues chaînes de caractères encodées en base64, fonctions eval(), appels vers des domaines externes inconnus. Supprimez le bloc malveillant ou restaurez le fichier depuis une sauvegarde saine.

Ne vous contentez pas de supprimer un seul fichier : les attaquants installent souvent des backdoors multiples pour maintenir l’accès.

Étape 5 : changer tous les mots de passe

• Mot de passe FTP
• Mot de passe base de données
• Mot de passe back-office PrestaShop (tous les comptes admin)
• Mot de passe hébergeur / panneau de contrôle
• Mot de passe email associé au domaine

Si l’attaquant a eu accès au back-office ou au FTP, il a potentiellement exfiltré ces credentials. Les changer coupe son accès futur.

Étape 6 : notifier vos clients et la CNIL

Rédigez un email aux clients potentiellement affectés pour les informer qu’ils doivent surveiller leurs relevés bancaires et faire opposition si nécessaire. Soyez directs et transparents : une communication honnête limite les dommages à votre réputation.

Déposez votre notification de violation sur le portail de la CNIL : notifications.cnil.fr

Pourquoi PrestaShop 1.6 et 1.7 sont particulièrement exposés

PrestaShop 1.6 n’est plus maintenu depuis 2019. PrestaShop 1.7 a atteint sa fin de vie en octobre 2023. Ces versions ne reçoivent plus aucun correctif de sécurité, ce qui signifie que les vulnérabilités découvertes depuis sont définitivement non corrigées.

Les attaques Magecart ciblent souvent des vulnérabilités connues dans des modules populaires ou dans le cœur de ces versions. Si vous tournez encore sur PS 1.6 ou 1.7, la migration vers PrestaShop 8.x n’est plus optionnelle du point de vue sécurité.

Prévention : durcir votre boutique après le nettoyage

Content Security Policy (CSP) : configurez un header CSP sur votre serveur pour bloquer l’exécution de scripts vers des domaines non autorisés. C’est la mesure la plus efficace contre les skimmers.

Modules anti-malware : des modules comme Watchdog Security Scanner ou NVS Security Scanner peuvent détecter des modifications suspectes de fichiers.

Mises à jour régulières : maintenez PrestaShop et tous vos modules à jour. La majorité des compromis exploitent des vulnérabilités corrigées dans des versions plus récentes.

Sauvegardes automatiques : une sauvegarde quotidienne permet de limiter la fenêtre de compromis et de restaurer rapidement.

Si votre boutique est actuellement compromise ou si vous avez des doutes, notre équipe intervient en urgence pour l’analyse forensique et le nettoyage complet. Consultez notre page urgence site PrestaShop pour une intervention rapide, ou notre offre de maintenance PrestaShop pour mettre en place une surveillance continue.