PrestaShop piraté : l'ordre pour protéger commandes et paiements

La home n'est pas le dossier

Un défacement se voit. Un skimmer, un employé créé à 3 h, un webhook PayPal tourné, non. Les boutiques que nous reprenons ont souvent déjà « remis le slider » deux fois. Le catalogue tourne, les cartes passent ailleurs. Partez du guide PrestaShop pour le cadre, et de cette page pour l'ordre opérationnel.

Constater : heure, URL de checkout, message client, ticket hébergeur. Copier le compte (fichiers + base) hors serveur. Changer le panel, puis le FTP, puis le back-office, puis les clés. Inverser laisse une session qui repose le module que vous venez de retirer. Premiers gestes.

Si une fausse page carte est en ligne, coupez cette URL tout de suite. Pour le reste, gardez la vitrine joignable tant que le paiement est isolé. Voir fermer la boutique ?.

Isoler le tunnel de paiement

Testez le checkout comme un client (privé, mobile). Notez l'URL finale de saisie carte. Si ce n'est pas votre PSP habituel, coupez ce module ou cette étape — pas toute la boutique. Quelques heures sans encaisser valent mieux que des transactions captées. Paiement redirigé et skimmer PrestaShop.

Désactivez les moyens de paiement suspects dans Paiement → Préférences / modules. Un bandeau « paiement temporairement indisponible » suffit souvent. Ne ne touchez pas encore aux commandes en cours : exportez-les.

Lisez le HTML de l'étape paiement. Un JS tiers inconnu, c'est un skimmer même si la redirection « a l'air » Stripe. Le 3-D Secure ne protège pas cette lecture — 3-D Secure.

• URL de checkout et de saisie carte notées.
• Modules paiement non reconnus : off.
• HTML de l'étape relu.

Employés, profils et webservice keys

Administration → Employés : comptes que vous ne nommez pas, heures aberrantes, profils trop ouverts (un « Catalogue » avec accès modules et commandes). Exportez, puis désactivez ou supprimez. Un profil trop large suffit parfois sans nouvel employé. Détail : employé fantôme.

Paramètres avancés → Webservice : clés que vous ne pouvez pas relier à un ERP, une app mobile, un marketplace. Révoquez. Une clé survit au mot de passe back-office. Même logique que clés API Magento.

Forcez la déconnexion (régénérer le cookie admin, changer `_COOKIE_KEY_` seulement si vous savez recoller — sinon changez les mots de passe employés et videz les sessions en table `ps_employee_session` selon version, après copie).

Modules de paiement et de transport

Listez les modules, dates, sources (Addons officiel vs zip email). Un module de paiement ou de transport que personne n'a installé est une porte classique. Désactivez, inspectez le dossier `modules/nom`, cherchez des appels sortants, ne « mettez pas à jour » depuis l'archive douteuse. Module transport inconnu.

Les overrides (`override/`) et les copies dans le thème (`themes/.../modules/`) survivent à une désactivation. Comparez au zip officiel du module et du cœur (selon votre branche 1.7 / 8 / 9). Un override de `PaymentModule` ou du checkout est prioritaire.

Commandes et clients fantômes

Commandes à 0 €, emails jetables, adresses incohérentes, pics de création de comptes, statuts « paiement accepté » sans passage PSP. Exportez avant de supprimer : ils figurent au constat et datent l'accès. Ils servent parfois à tester que l'attaquant a la main, parfois à faire transiter du contenu.

Ne « remboursez pas tout » dans le vide. Les vraies commandes de la fenêtre restent des vraies commandes. Le tri se fait avec le PSP — Stripe, PayPal.

Données : ce que PrestaShop a vraiment

PrestaShop ne stocke en principe pas le PAN complet. Noms, emails, adresses, historiques, parfois IBAN ou tokens, oui. Un accès back-office ou une clé webservice lecture sur customers / orders est une lecture possible. Le constat technique dit si les tables ont été touchées ou exportées. C'est ce document qui sert à la CNIL, pas une impression. Fuite de données.

Ne publiez pas « aucune donnée client n'a fuité » le soir même. Un démenti trop tôt se retourne. La notification, si elle est due, vous incombe.

Nettoyer sans réinstaller « à neuf »

Comparez le cœur au zip officiel de votre version exacte, retirez les PHP hors arbre, alignez les modules Addons, conservez `img/`, le catalogue, les commandes. Une sauvegarde PrestaShop « last » contient souvent déjà le skimmer. On remonte jusqu'à un point relu, on ne restore pas par réflexe.

Les tables `ps_configuration` (URLs, emails, parfois extra HTML), `ps_hook` / `ps_hook_module`, et les contenus CMS : grep `<script` et des domaines inconnus. Même famille que les options WordPress, autre schéma.

Thème, override et JavaScript de checkout

Le thème enfant / le theme child PrestaShop et `themes/votre-theme/assets/js` portent trop souvent le skimmer. Comparez à l'archive du thème. Un `custom.js` de 2024 avec trois lignes ajoutées en bas : lisez-les. Videz les caches PrestaShop + CDN après. Sans ça, le HTML sale est encore servi.

Les webhooks modules (Stripe officiel vs zip nulled) : vérifiez les URLs chez le prestataire. Module Stripe officiel vs nulled et webhooks.

Informer, ou pas, puis surveiller

Pas d'accès données ni de paiement détourné établi : une com large crée de la panique. Risque cartes : clients concernés, banque / PSP, fenêtre de dates. Que dire aux clients, informer la banque.

Surveillez employés et modules 30 jours. Relisez le HTML checkout à J+2 et J+7. Pour un constat et un nettoyage sans perdre le catalogue, déclarez la boutique — le prix s'affiche avant l'accès. La page service : PrestaShop piraté.

• Paiement isolé, vitrine utile.
• Employés et clés webservice relus.
• Modules inconnus désactivés, dossiers lus.
• PSP informé si le HTML checkout était sale.