La sécurité des modules PrestaShop est un enjeu souvent sous-estimé par les marchands et les développeurs. Pourtant, un module vulnérable peut exposer toute la boutique à des cyberattaques.
Chez TouchWeb, nous avons fait de la sécurité module PrestaShop une priorité stratégique, en mettant en place une méthode d'audit rigoureuse, une charte de cybersécurité responsable et un partenariat en création avec la plateforme YesWeHack et PrestaShop SA.
Ce guide complet vous présente notre approche et les solutions concrètes à adopter.
Pourquoi la sécurité des modules PrestaShop est-elle importante ?
Un module PrestaShop, même anodin en apparence, peut avoir des accès profonds au système : base de données, back-office, fichiers du serveur… S'il est mal conçu, il devient une porte d'entrée idéale pour un attaquant.
Voici des vulnérabilités couramment identifiées :
- Injections SQL dans les paramètres non filtrés
- Faille XSS dans les formulaires ou les notifications
- Escalade de privilèges par mauvaise gestion des droits
- Attaques CSRF sur les actions sensibles
- Envoi de fichiers malveillants
Chaque audit que nous menons révèle que la sécurité des modules PrestaShop est encore trop négligée par de nombreux éditeurs dont la conscience professionnelle est souvent inversement proportionnelle à la distance qui les sépare d'un pays soumis à la législation Européenne (RGPD).
Audit de sécurité des modules PrestaShop : un travail indispensable lors de chaque reprise
Lorsqu'un site PrestaShop est migré ou repris dans un nouveau contexte technique, il est essentiel de procéder à un audit de sécurité des modules installés.
Ce travail représente un investissement important en temps, souvent étalé sur plusieurs jours, car il implique :
- 🛠️ Une revue manuelle de chaque module
- 🔍 L'identification de vulnérabilités critiques, de fuites de données ou de comportements à risque
- 🔧 La stabilisation du socle en traitant les composants obsolètes ou mal conçus
Cette étape permet de repartir sur une base propre, documentée et techniquement cohérente. Elle évite de réintégrer des failles existantes dans un environnement censé être sécurisé.
Pour les plus techniques d'entre vous
L'audit comprend l'analyse détaillée des éléments suivants :
- Tous les FrontControllers
- Les scripts AJAX accessibles depuis le front
- Les fichiers PHP autonomes exposés directement
- Les surcharges de classes du cœur ou de modules tiers
L'analyse s'appuie sur une trentaine de classes de vulnérabilités, incluant notamment :
- CWE-22 – Path Traversal
- CWE-79 – Cross-Site Scripting (XSS)
- CWE-89 – SQL Injection
Ces classes de vulnérabilités sont couramment rencontrées dans des modules développés sans cadre de sécurité rigoureux.
Ce travail d'audit est inclus dans l'ensemble des forfaits d'infogérance PrestaShop que nous proposons, afin de poser les bases d'une relation commerciale durable et techniquement saine.
Notre engagement RSE en matière de divulgation des vulnérabilités
Dans le cadre de notre responsabilité sociétale, nous considérons que la cybersécurité ne peut se limiter à la seule protection de nos clients.
Lorsqu'une faille de sécurité PrestaShop est identifiée, notre sens de l'éthique et notre engagement RSE nous imposent de respecter les bonnes pratiques de l'industrie.
Concrètement, cela signifie que :
- 📢 Nous publions chaque vulnérabilité confirmée via une note de sécurité bénéficiant d'un identifiant CVE (Common Vulnerabilities and Exposures)
- 🕊️ Nous respectons un processus de divulgation responsable, en coordination avec l'éditeur du module ou l'équipe concernée
- 📚 Nous contribuons ainsi à la documentation publique des risques, afin de renforcer la sécurité globale de l'écosystème PrestaShop
Cette démarche s'inscrit dans une volonté de transparence et de progrès collectif. Nous estimons que chaque vulnérabilité corrigée publiquement est une opportunité de faire évoluer les pratiques et de mieux outiller la communauté.
Vers une charte : poser un cadre dans un écosystème sans règle
Après deux années à publier publiquement des vulnérabilités dans des modules PrestaShop - conformément aux standards internationaux et à notre responsabilité éthique - nous avons dû faire face à une réalité inconfortable : l'absence de cadre formel dans l'écosystème PrestaShop.
Cette absence de règles a généré des tensions fortes entre 2022 et 2024. Nous avons été confrontés à :
- 📄 Des éditeurs refusant toute reconnaissance publique des failles découvertes dans leurs modules
- ⚠️ Des menaces de procédures pour diffamation malgré une divulgation conforme à l'état de l'art
- ❌ Des relations rompues avec certains concepteurs peu soucieux des enjeux de sécurité
Dans ce contexte, il est devenu clair qu'à défaut de pouvoir constituer légalement une liste des éditeurs à risque, il fallait structurer l'effort inverse : établir une liste positive d'acteurs engagés.
C'est ainsi qu'est née notre charte de cybersécurité responsable dédiée aux éditeurs de modules PrestaShop. Elle vise à :
- 🧾 Établir un socle commun d'engagements clairs et réalistes
- 🤝 Valoriser les éditeurs qui corrigent rapidement, documentent leurs vulnérabilités et acceptent l'échange
- 🏷️ Permettre aux e-commerçants de mieux identifier les modules développés avec rigueur et sérieux
Cette charte n'est pas une sanction, mais une reconnaissance : celle des éditeurs qui acceptent que la sécurité soit une démarche continue, collective et responsable.
Pourquoi une société privée (TouchWeb) porte cette initiative ?
Vous êtes nombreux à nous demander pourquoi nous portons la charte plutôt que PrestaShop SA ou l'association Friends of Presta. Voici des éléments de réponse.
Pourquoi aucune société mère ne peut le faire ?
Il est important de bien comprendre que la cybersécurité repose sur deux volets bien distincts : le préventif d'un côté (renforcement des processus qualité), et le curatif de l'autre (gestion des vulnérabilités post-déploiement).
Les sociétés mères (PrestaShop SA pour PrestaShop, Adobe pour Magento, Automattic pour WooCommerce) font un travail remarquable sur la partie préventive, notamment à travers la rédaction de guides de bonnes pratiques, et dans le cas de la marketplace PrestaShop, via l'intégration d'une solution professionnelle de relecture automatique du code avec AppScan.
Cette phase préventive est donc bien couverte. La suite de notre propos concerne exclusivement le curatif - c'est-à-dire les vulnérabilités qui ont échappé aux mailles des filets des processus qualité.
Dans le cas de PrestaShop, PrestaShop SA occupe une position centrale à la fois technique et commerciale. Elle doit encourager les développeurs à produire des modules, à les publier sur la marketplace, et à enrichir l'offre globale autour de la solution.
Dans ce contexte, tenir un rôle d'accélérateur tout en assumant celui de régulateur devient un exercice politique de haute voltige. Il lui est (très) difficile de :
- 🚀 Recruter ou incuber des concepteurs de modules pour dynamiser l'écosystème
- ⚠️ Tout en publiant leurs vulnérabilités, ce qui - faute d'une sensibilisation suffisante à la cybersécurité - est souvent mal perçu par les développeurs
Ce double rôle - soutien d'un côté, sanction de l'autre - crée un conflit d'intérêt structurel. Et cela dépasse largement le cas de PrestaShop :
aucune société mère n'a jamais publié de vulnérabilités concernant les modules de son propre écosystème.
Magento ne publie pas les failles de ses modules tiers, WordPress non plus - ce rôle est assuré par des entités externes comme Wordfence, WPScan ou PathStack.
Pourquoi nous ne souhaitons plus le faire sous l'égide de l'association Friends of Presta ?
L'association Friends of Presta (FOP) joue un rôle essentiel dans l'animation de la communauté PrestaShop : organisation d'événements, soutien aux contributions open source, mise en relation entre acteurs de l'écosystème…
Pendant un temps, nous avons mené ces actions de sécurité sous son égide. Mais plusieurs limites se sont rapidement posées :
- 🤐 Une association repose sur la recherche constante de consensus. Or, la sécurité est un domaine qui exige parfois de trancher, d'exposer, voire de déranger - ce qui est difficile à assumer collectivement.
- 🎯 Les priorités de l'association sont larges (animation, évangélisation, entraide), là où la cybersécurité impose un cap clair, des délais courts, et des positions fermes.
- 🤝 Enfin, toute initiative portée sous une bannière associative engage de fait la responsabilité de ses membres et partenaires - ce qui peut freiner certaines actions jugées sensibles ou clivantes.
Pour toutes ces raisons, nous pensons qu'un cadre privé, assumé et indépendant permet une action plus cohérente, plus rapide, et plus lisible - sans faire porter à d'autres les conséquences de décisions difficiles mais nécessaires.
Pourquoi TouchWeb ne peut plus se fondre dans un projet tiers ?
Relire le programme de modules PrestaShop tiers est un exercice complexe et particulièrement chronophage. Il demande de s'immerger dans des bases de code que nous n'avons pas écrites, parfois mal structurées, sans documentation, et parfois volontairement obscures. Cela suppose de maîtriser à la fois PrestaShop, PHP, les vecteurs d'attaque modernes, et les standards de vulnérabilités (CWE, OWASP, etc.).
Pendant plusieurs années, nous avons mené ce travail à nos frais, sans commande, sans mandat, et surtout sans soutien structuré. Nous avons tout fait pour le partager : rédaction de CVE publics, transmission des vulnérabilités aux éditeurs, documentation accessible, et même formations gratuites pendant plusieurs mois pour sensibiliser la communauté.
Nous avons offert tout cela sans jamais attendre de retour financier, en toute lucidité : dans l'écosystème PrestaShop, il n'existe aucun budget dédié à la cybersécurité curative. Cela ne nous a pas découragés, mais force est de constater que nos efforts ont été trop souvent accueillis avec indifférence, méfiance ou mépris.
Nous aurions espéré davantage d'appui, ou au minimum, de reconnaissance. Dans la plupart des cas, nos signalements ont été ignorés, minimisés, ou perçus comme une attaque personnelle. Dans les pires cas, nous avons essuyé des menaces ou des pressions.
Cette absence de retour positif a pesé. Elle montre que la culture de sécurité est encore en construction, et que ceux qui signalent les problèmes sont trop souvent perçus comme dérangeants plutôt que comme contributeurs utiles.
Plus dérangeant encore : l'ensemble des données que nous avons partagées librement - alertes, CVE, documentation, méthodologie - a été repris et exploité par certaines sociétés à des fins purement commerciales, souvent sans mention, sans demande préalable, et sans la moindre tentative de collaboration ou d'aide. Certaines de ces sociétés ont directement valorisé ce travail dans leurs propres offres, tout en restant totalement absentes des efforts de fond que nous avons portés.
Il est temps que le secteur reconnaisse que la cybersécurité ne se construit ni dans le silence, ni dans la complaisance, ni dans l'isolement. Elle se construit par des actes concrets, parfois dérangeants, toujours nécessaires.
Pour que cette mission puisse perdurer, TouchWeb a besoin de s'épanouir sous son propre nom. C'est une condition indispensable pour que les efforts en cybersécurité curative - qui ne génèrent aucune ligne de revenu directe - puissent être soutenus par la valeur de nos autres expertises.
Ce modèle d'équilibre ne peut exister sous la coupe ou la dilution d'un autre projet, aussi respectable soit-il.
Et maintenant ? Une réponse structurée avec YesWeHack
Après plusieurs années à assumer une part substantielle des efforts de veille et d'audit, il est devenu nécessaire de réévaluer notre manière de contribuer et de la faire évoluer.
Face à l'absence totale de budget structuré pour la cybersécurité curative, mais aussi pour désengorger notre bande passante et impliquer davantage la communauté, nous avons décidé de passer d'un modèle entièrement bénévole à un modèle pragmatique, structuré et incitatif.
Désormais, toutes les failles identifiées dans les modules PrestaShop seront remontées via la plateforme YesWeHack, dans le cadre d'un programme privé. Cela nous permet :
- 🎯 D'impliquer des chercheurs en cybersécurité professionnels
- 🔐 D'assurer une gestion responsable, encadrée et confidentielle des vulnérabilités
- 💸 De verser des primes financières à ceux qui prennent le relais de notre veille
En l'absence de toute contribution collective, ces primes sont aujourd'hui entièrement financées sur les marges commerciales de TouchWeb. Aucun client ne les paie. Aucun éditeur ne les finance. Aucun acteur institutionnel n'y contribue.
Seuls les concepteurs distribuant leurs modules sur la PrestaShop Marketplace et ayant adhéré à notre charte de cybersécurité responsable seront éligibles à ce programme. Ce choix vise à concentrer les efforts là où l'impact est le plus large, et où existe un minimum de visibilité contractuelle et commerciale.
C'est un choix assumé. Parce que si personne ne veut ou ne peut financer la cybersécurité curative, nous le ferons nous-mêmes - pour protéger nos clients, notre écosystème, et l'intégrité d'un projet auquel nous croyons profondément.
Un mot pour les marchands
Si vous êtes marchand, soucieux de la confidentialité des données de vos clients, de la fiabilité de votre boutique et de votre conformité réglementaire, alors vous devez impérativement vous intéresser aux politiques de sécurité des modules que vous utilisez.
Avant tout achat ou installation, prenez le temps de vous poser ces questions importantes :
- 🔍 Le concepteur a-t-il une politique de cybersécurité publique ? nous les listons ici
- 📢 A-t-il déjà communiqué sur des failles corrigées ? Ou au contraire, a-t-il toujours gardé le silence ?
- 🛠️ A-t-il un processus de correctif (patch) à déployer "rapidement" ?
Un module sans politique de sécurité claire est un risque pour votre activité. Ce n'est pas parce qu'il fonctionne aujourd'hui qu'il résistera demain à une attaque ciblée ou à une faille exposée publiquement.
À l'inverse, privilégier les éditeurs de module ayant adhéré à notre charte de cybersécurité responsable, c'est faire le choix d'une relation saine et durable fondée sur la transparence.
Cela ne garantit pas l'absence totale de vulnérabilité - aucun acteur sérieux ne peut faire cette promesse. Mais cela vous garantit une chose essentielle : vous serez informé rapidement, vous pourrez appliquer un correctif dans les meilleurs délais, et vous ne serez pas seul face au problème.
Vous pouvez facilement identifier les adhérents à notre charte via ce badge dans leurs modules :
⚠️ Veillez toutefois à vérifier qu'ils sont bien officiellement listés sur notre page de référence, seule source vérifiable garantissant leur engagement réel.
Tout comme nous, vous comprenez le sens profond des mots souveraineté, prédictibilité et réversibilité - des piliers fondateurs de l'Open Source et de PrestaShop.
Dans un contexte où nos écosystèmes libres sont de plus en plus pris pour cible par les logiques de plateformes SaaS propriétaires, il devient essentiel de rester soudés autour de ces valeurs.