Les trois formes d'un détournement de paiement
La copie des cartes pendant la saisie. Un script ajouté à la page de commande lit ce que le client tape et l'envoie vers un serveur tiers. Le paiement aboutit normalement : ni le client ni le marchand ne voient rien, jusqu'aux premières fraudes sur les cartes. On parle de skimming en JavaScript.
La redirection vers une fausse page de paiement. Au moment de payer, le client est envoyé sur une page qui imite celle du prestataire. Il saisit sa carte, voit un message d'erreur, puis repaie sur la vraie page. Signe fréquent : des clients qui se plaignent d'avoir dû payer deux fois.
Le changement des coordonnées de réception. L'IBAN affiché pour le paiement par virement, ou l'identifiant du compte du prestataire de paiement, est remplacé dans la configuration. Les commandes passent, l'argent part ailleurs, et le marchand ne s'en aperçoit qu'au rapprochement bancaire.
Sur PrestaShop : ce que l'auditeur contrôle
Une boutique PrestaShop est hébergée par vous. L'attaquant qui obtient un accès peut modifier n'importe quel fichier ou réglage : l'audit compare donc ce qui tourne en ligne avec ce qui devrait y être.
- Les modules de paiement — Fichiers des modules de paiement comparés à la version officielle de l'éditeur, module de paiement inconnu ajouté, réglages modifiés : identifiants du prestataire, URL de retour, IBAN du module de virement.
- Les scripts des pages de commande — Fichiers JavaScript du thème et des modules chargés sur le panier et le tunnel de commande, code ajouté en fin de fichier, appels vers des domaines que la boutique n'utilise pas.
- Les surcharges et le code spécifique — Dossier override, classes surchargées, code développé pour la boutique : une surcharge discrète du contrôleur de commande suffit à détourner un paiement.
- Les modules tiers et leurs failles connues — Liste des modules installés, version, date de la dernière mise à jour, failles publiées : injection SQL, téléversement de fichiers, accès sans authentification. Un module abandonné est la porte d'entrée la plus courante.
- Le contenu de la base — Scripts injectés dans les pages CMS, les blocs de texte, les réglages du thème ou les champs de configuration, que l'on ne voit pas en relisant les fichiers.
- L'administration et le serveur — Comptes employés inconnus, dossier d'administration, fichiers d'installation ou de sauvegarde restés en ligne, version de PrestaShop et de PHP, droits d'écriture sur les fichiers.
Sur Shopify : ce que l'auditeur contrôle
Shopify héberge la boutique et la page de paiement. Le risque se déplace : il porte sur ce que vous avez installé, configuré et donné comme accès, et sur les pages qui précèdent le paiement.
- Les comptes et les accès — Comptes du personnel et leurs droits, double authentification, accès collaborateurs donnés à des agences ou à d'anciens prestataires, propriétaire de la boutique.
- Les applications installées — Chaque application et ses autorisations : lecture des commandes et des clients, modification du thème. Une application qui peut écrire dans le thème peut y ajouter un script.
- Le code du thème — Scripts ajoutés dans la mise en page, sur la page produit et le panier, liens de paiement ou boutons qui envoient le client hors du tunnel Shopify.
- Les pixels et scripts tiers — Pixels personnalisés, outils de suivi, chat, avis clients : ce qu'ils chargent, ce qu'ils lisent et vers où ils envoient les données.
- Les applications personnalisées et l'API — Jetons d'accès à l'API d'administration, leur portée, où ils sont stockés, webhooks qui envoient les commandes vers une adresse inconnue.
- Les moyens de paiement manuels — Instructions de paiement par virement ou autre moyen manuel : les coordonnées affichées au client sont-elles bien les vôtres ?
Les signes qui doivent déclencher un audit
- Des clients disent avoir payé deux fois — Typique d'une fausse page de paiement placée avant la vraie.
- Des fraudes sur les cartes de vos clients — Votre banque ou votre prestataire de paiement vous signale des cartes compromises qui ont toutes servi chez vous.
- Des commandes payées sans encaissement — Commandes validées par virement ou par un moyen de paiement dont l'argent n'arrive jamais sur votre compte.
- Un compte ou une application inconnus — Un employé, un collaborateur, une application ou un module que personne ne se souvient d'avoir ajouté.
- Des fichiers modifiés sans mise à jour — Sur PrestaShop, des fichiers de modules ou du thème dont la date de modification ne correspond à aucune intervention.
Si le détournement est en cours
Désactivez le moyen de paiement touché et prévenez votre prestataire de paiement. Conservez une copie des fichiers, de la base et des journaux avant de nettoyer : c'est ce qui permettra à l'expert de trouver la porte d'entrée. Changez ensuite les mots de passe des comptes d'administration et les jetons d'API.
Si des données personnelles de clients ont été exposées, le RGPD impose de notifier la CNIL dans les 72 heures après en avoir pris connaissance. Un audit après incident sert à la fois à fermer la faille et à documenter ce qui s'est passé.
Comment se déroule l'audit
- Cadrage et autorisation écrite — Périmètre (boutique, administration, modules ou applications, serveur pour PrestaShop), dates, accord de confidentialité et autorisation signée avant tout test.
- Inventaire — Version de la plateforme, liste des modules ou applications, comptes, scripts tiers, intégrations et moyens de paiement actifs.
- Contrôle d'intégrité — Sur PrestaShop, comparaison des fichiers avec les versions officielles du cœur et des modules ; sur Shopify, revue du thème et des autorisations des applications.
- Test du parcours de commande — Commande de test du panier jusqu'au paiement, en observant chaque script chargé et chaque redirection, puis test de l'administration comme le ferait un attaquant.
- Rapport et contre-vérification — Failles classées par gravité avec leurs preuves, corrections priorisées en commençant par le paiement, puis seconde passe après vos corrections.
Confier l'audit de votre boutique sur Hackersdate
Publiez votre besoin gratuitement : plateforme et version, modules ou applications installés, moyens de paiement, ce qui vous alerte. Ne mettez aucun mot de passe ni accès dans l'annonce : ils se transmettent ensuite à l'expert retenu.
Des hackers éthiques indépendants vous répondent avec leur méthode, leur délai et leur prix ; chacun dépense 1 crédit par proposition. Le paiement est déposé sur Stripe et n'est versé à l'expert qu'à la livraison, quand vous libérez les fonds et laissez votre avis. Hackersdate prélève une commission de 2 %.
Questions fréquentes
Un expert vérifié pour votre besoin
Publiez votre besoin en deux minutes : des hackers éthiques vérifiés vous répondent, le paiement reste bloqué jusqu'à la livraison.
Publier mon besoin