Audit de sécurité PrestaShop : que faut-il réellement contrôler ?

Un audit de sécurité PrestaShop ne se limite pas à lancer un scanner ou à vérifier que le cadenas HTTPS apparaît dans le navigateur. Une boutique est exposée par son cœur, ses modules, ses comptes d’administration, son serveur, ses accès techniques et ses données clients. L’objectif est d’identifier les composants vulnérables, les configurations dangereuses et les traces d’une éventuelle compromission, puis de corriger les risques dans le bon ordre. Voici une méthode concrète pour contrôler une boutique PrestaShop, qu’elle soit en production, reprise après une migration ou suspectée d’avoir été piratée.

1. Identifier précisément la version et l’environnement

Commencez par documenter ce qui est réellement installé. Relevez la version exacte de PrestaShop depuis le back-office, dans Paramètres avancés > Informations, ou dans le fichier config/settings.inc.php selon la version. Notez également la version de PHP, du serveur web, de la base de données et le système d’exploitation si vous avez accès à l’hébergement.

Une version ancienne de PrestaShop ou de PHP n’est pas automatiquement compromise, mais elle peut ne plus recevoir de correctifs. Vérifiez la compatibilité avant toute mise à niveau : un passage de PHP 7.4 vers PHP 8.1 ou 8.2, par exemple, doit être testé sur une préproduction avec le thème et les modules actifs.

• Contrôlez que la boutique utilise une version maintenue de PrestaShop.
• Comparez la version de PHP aux prérequis de cette version de PrestaShop.
• Vérifiez que HTTPS est forcé sur le front-office et le back-office.
• Listez les accès actifs : hébergement, SFTP, SSH, base de données, CDN, compte e-mail transactionnel et prestataire de paiement.

2. Examiner les comptes et les accès au back-office

Les identifiants volés restent une cause fréquente d’accès non autorisé. Dans Paramètres avancés > Équipe ou dans la gestion des employés selon votre version, examinez chaque compte : nom, adresse e-mail, profil, dernière connexion et nécessité réelle de l’accès. Supprimez les comptes d’anciens prestataires, de stagiaires ou de collaborateurs qui n’interviennent plus.

Appliquer le principe du moindre privilège

Un préparateur de commandes n’a pas besoin du droit de modifier les modules, les employés ou les réglages de paiement. Créez des profils adaptés aux tâches réelles et attribuez les permissions avec précision. Le compte super-administrateur doit être réservé aux opérations d’administration.

Utilisez des mots de passe uniques et longs pour le back-office, l’hébergement et les boîtes e-mail associées. Lorsque votre hébergeur, un reverse proxy ou un module fiable le permet, ajoutez une authentification multifacteur ou une restriction d’accès au back-office par adresse IP. Une restriction IP est utile pour une petite équipe fixe, mais elle doit prévoir une procédure d’accès d’urgence pour les déplacements ou les interventions de maintenance.

3. Contrôler le cœur, les overrides et les fichiers modifiés

Le contrôle d’intégrité cherche des fichiers ajoutés ou modifiés en dehors des changements attendus. Comparez les fichiers du cœur avec l’archive officielle correspondant exactement à votre version de PrestaShop. Ne remplacez pas aveuglément des fichiers en production : les modifications peuvent provenir d’un correctif légitime, d’un override ou d’une personnalisation ancienne.

Examinez en priorité les répertoires et fichiers sensibles :

• classes/, controllers/, config/ et override/ ;
• les répertoires d’administration renommés, souvent de type admin123 ;
• modules/, notamment les modules récemment ajoutés ou inconnus ;
• img/, upload/, download/ et les caches, où des fichiers exécutables ne devraient pas apparaître sans raison ;
• les fichiers .htaccess, index.php, tâches cron et scripts placés à la racine.

Recherchez les fichiers PHP récemment modifiés et les motifs typiques de code obfusqué : longues chaînes encodées, appels inhabituels à base64_decode(), eval(), gzinflate() ou chargement de code distant. Ces fonctions ne prouvent pas à elles seules une infection, mais elles justifient une revue manuelle du contexte. Vérifiez aussi les overrides : un override inattendu dans override/classes peut modifier le comportement des commandes, des clients ou des paiements.

4. Auditer les modules, thème et connecteurs externes

Les modules constituent la surface d’attaque la plus variable d’une boutique. Dans le gestionnaire de modules, établissez un inventaire : nom technique, éditeur, version, date de dernière mise à jour, rôle métier et source d’acquisition. Désactivez puis supprimez les modules inutilisés après sauvegarde. Un module désactivé mais conservé sur le serveur peut encore représenter un risque s’il contient une faille accessible directement.

Pour chaque module critique — paiement, transport, synchronisation ERP, marketplace, export comptable, consentement, e-mail — vérifiez qu’il provient de l’éditeur ou d’une place de marché reconnue, qu’il est compatible avec votre version de PrestaShop et qu’une mise à jour de sécurité n’est pas disponible. Évitez les archives téléchargées depuis des sources non vérifiables et les modules « nulled » : ils peuvent contenir des portes dérobées.

Ne pas oublier le thème

Un thème peut embarquer des contrôleurs, des formulaires, des bibliothèques JavaScript et des overrides. Contrôlez ses mises à jour, ses dépendances et les scripts tiers chargés sur les pages de paiement. Un script ajouté dans le thème ou via un module de suivi peut exfiltrer des données de formulaire. Limitez les balises externes aux services nécessaires et vérifiez leur origine dans le code source et dans l’onglet Réseau des outils de développement du navigateur.

5. Vérifier la configuration serveur et les permissions

PrestaShop doit pouvoir écrire dans certains dossiers, notamment pour le cache, les images ou les téléchargements. Cela ne justifie pas des permissions trop ouvertes. Évitez les droits 777 sur les fichiers et dossiers lorsque la configuration de l’hébergement permet des droits plus restrictifs. En pratique, les fichiers sont souvent en 644 et les dossiers en 755, mais la bonne configuration dépend de l’utilisateur utilisé par PHP et de l’hébergeur.

Les fichiers de configuration, tels que app/config/parameters.php sur certaines versions récentes ou config/settings.inc.php sur les versions antérieures, contiennent les identifiants de base de données. Ils ne doivent jamais être accessibles publiquement, versionnés dans un dépôt public ou envoyés par e-mail non sécurisé.

• Désactivez l’affichage des erreurs PHP en production ; les erreurs doivent être consignées dans des logs, pas affichées aux visiteurs.
• Vérifiez les journaux d’accès et d’erreurs du serveur, ainsi que les logs PrestaShop.
• Contrôlez les tâches cron : URL appelée, fréquence, jeton de sécurité et propriétaire du script.
• Assurez-vous que les sauvegardes et exports ne sont pas accessibles par une URL publique prévisible.
• Vérifiez la configuration du pare-feu applicatif ou du WAF proposé par l’hébergeur, sans bloquer les flux légitimes de paiement et de transport.

6. Examiner les données et les signes de compromission

Un audit sérieux inclut des contrôles fonctionnels et des recherches d’anomalies. Consultez les employés récemment créés, les changements de coordonnées bancaires, les règles de panier inhabituelles, les bons de réduction inconnus, les redirections et les modifications de templates. En base de données, comparez les tables de configuration et de contenu avec une sauvegarde saine si vous en disposez. Ne supprimez pas une donnée suspecte sans conserver une copie : elle peut être utile pour comprendre le vecteur d’intrusion.

Surveillez particulièrement les e-mails de réinitialisation de mot de passe non sollicités, les commandes frauduleuses, les redirections vers des domaines inconnus, les pages qui chargent des scripts inattendus et les pics de requêtes vers des fichiers PHP atypiques. En cas de suspicion fondée, placez la boutique en maintenance si nécessaire, conservez les logs, changez les identifiants depuis un poste sain et faites analyser les fichiers avant de restaurer.

7. Prioriser les corrections et instaurer un suivi

Classez les constats selon leur impact et leur exposition. Une faille connue dans un module de paiement accessible publiquement, un compte administrateur inconnu ou un fichier malveillant doit être traité immédiatement. Viennent ensuite les composants obsolètes, les accès trop larges et les défauts de durcissement. Les améliorations de confort, comme le nettoyage de modules sans usage direct, peuvent être planifiées après les urgences.

1. Effectuez une sauvegarde complète, testez sa restauration sur un environnement séparé et conservez-la hors du serveur de production.
2. Corrigez ou isolez les éléments compromis et révoquez les accès concernés.
3. Mettez à jour PrestaShop, les modules et le thème après test sur une préproduction.
4. Documentez les modifications, les versions et les personnes ayant accès à la boutique.
5. Planifiez un contrôle mensuel des mises à jour et un audit plus complet après une migration, une reprise de site ou l’ajout d’un connecteur sensible.

Un audit utile se termine donc par une liste d’actions vérifiables : composant à mettre à jour, fichier à analyser, compte à supprimer, réglage à modifier et responsable désigné. Cette traçabilité évite que les mêmes risques réapparaissent après la prochaine intervention technique.