La sécurité d'une boutique e-commerce ne repose pas uniquement sur son hébergement ou son WAF. Elle commence dès le choix du CMS, dont la conception structurelle (by design) doit faire l'objet d'une analyse approfondie.
Dans la suite de cet article, nous parlerons exclusivement de cybersécurité applicative à un niveau professionnel (expertise DevSecOps). Certaines notions pourront sembler complexes si vous n'êtes pas technicien de métier - mais elles sont essentielles pour qui veut comprendre les enjeux réels.
À ceux qui auront la curiosité (ou le courage) d'explorer les rouages internes de PrestaShop : vous découvrirez une solution particulièrement bien pensée, avec de solides arguments en matière de sécurité.
En résumé, vous aurez les arguments techniques pour défendre la sécurité PrestaShop.
Les IDOR (nom de code CWE-639) comptent parmi les vulnérabilités PrestaShop les plus critiques, tant en termes d'impact que de taux de pénétration. Pourquoi ? Parce qu'elles permettent à un utilisateur légitime en apparence d'accéder à des ressources qui ne lui sont pas destinées, en manipulant simplement un identifiant dans l'URL.
Et c'est précisément là que le bât blesse : ces attaques ne déclenchent généralement aucune alerte côté WAF. Elles passent sous les radars, car elles exploitent une faiblesse logique dans la vérification des droits d'accès. Pour un WAF, tout semble “normal” : un utilisateur fait une requête bien formée, sans charge malveillante apparente. Ce sont des ennemis de l'intérieur, silencieux, et souvent indétectables sans une vraie analyse métier.
Là où PrestaShop se distingue, c'est dans sa conception même : les comptes administrateurs et les comptes clients sont physiquement séparés, avec des tables, des contrôleurs et des interfaces distincts. Contrairement à d'autres CMS comme WordPress, où un compte client peut parfois évoluer en compte admin ou partager des mécanismes communs, cette séparation réduit drastiquement les risques d'escalade de privilèges.
En pratique, cela neutralise toute tentative d'exploitation d'une IDOR visant à se connecter illicitement à un compte administrateur.
Lors de son installation, PrestaShop génère automatiquement un répertoire d'administration aléatoire, par exemple /admin893xvc/. Cette approche rend les attaques par force brute ou les scans automatisés bien plus difficiles.
Contrairement à d'autres solutions, il n'existe aucun lien croisé entre le front-office et le back-office.
PrestaShop bénéficie ainsi d'une isolation stricte, ce qui facilite considérablement le déploiement de mesures de sécurité avancées, comme la restriction d'accès par adresse IP.
Cela renforce également la sécurité contre les attaques XSS de type 1 (Reflected XSS) contribuant à réduire la surface d'attaque.
À l'inverse d'autres CMS comme WordPress, aucun risque de voir le lien de connexion au back-office exposé sur le frontend à cause d'un module nécessitant une authentification.
Ce cloisonnement réduit fortement la surface d'attaque côté administration - un vrai plus pour la sécurité PrestaShop.
PrestaShop intègre nativement un système de jetons anti-CSRF dans son back-office.
Ce mécanisme protège automatiquement les formulaires et les actions critiques contre les attaques de type CSRF (Cross-Site Request Forgery) - c'est-à-dire l'envoi de requêtes malveillantes via un formulaire HTML piégé, généralement hébergé sur un site tiers et destiné à tromper un administrateur, notamment via des campagnes de phishing.
Cette protection est d'autant plus efficace que, comme évoqué précédemment, le chemin d'accès au back-office est généré de manière aléatoire lors de l'installation. Ce comportement rend l'interface d'administration difficile à cibler par des attaques automatisées, ajoutant une couche supplémentaire de sécurité contre les tentatives de CSRF.
L'API de PrestaShop est exclusivement destinée aux traitements backend (ERP, WMS, PIM, etc.).
Elle n'est pas exposée publiquement par défaut, et son accès est strictement encadré par un système de clés API et de permissions granulaires.
Contrairement à WordPress (WooCommerce), qui expose son API via /wp-json/ - un point d'entrée commun utilisé à la fois par le frontend et le backend - l'architecture de PrestaShop permet de surveiller précisément les flux entrants. Il est ainsi possible de mettre en place une écoute des appels API pour s'assurer que chaque requête provient d'un système autorisé, et non d'un acteur malveillant ayant subtilisé une clé ou injecté un accès non légitime.
Ce contrôle granulaire des flux backend renforce la sécurité PrestaShop dans les environnements interconnectés.
PrestaShop permet à chaque module de déclarer ses propres contrôleurs avec des routes explicites, du type /module/module_name/action.
Contrairement à WordPress, qui centralise les appels via un unique point d'entrée wp-admin/admin-ajax.php, rendant difficile tout filtrage avancé ou restriction IP par fonctionnalité, PrestaShop facilite grandement l'identification et la sécurisation des actions spécifiques à chaque module.
Attention toutefois : PrestaShop autorise nativement l'« invisibilisation » totale des appels vers les front controllers. Cette pratique doit absolument être interdite via votre WAF, sous peine de rendre l'analyse de logs impossible - en particulier si votre hébergeur ne respecte pas l'état de l'Art en matière de journalisation.
Pour les plus techniques d'entre vous, voici ce que nous appelons une « invisibilisation » : curl -d 'fc=module&module=module_name&controller=a--c-t---i-o---n' https://preprod.X/ Veuillez noter la distribution aléatoire des tirets.
Cela génère, côté frontend, le journal suivant : POST /. Si votre hébergeur ne respecte pas l'état de l'Art en refusant de journaliser le corps (BODY) des requêtes HTTP, il devient alors impossible de savoir quel contrôleur de quel module a été appelé.
PrestaShop bénéficie d'un modèle de données clair et bien segmenté, sans recourir à une sérialisation massive ni à des tables « fourre-tout ».
Cette organisation rend l'analyse de la base de données à la fois rapide et fiable. Par exemple, il est très simple de scanner la base pour détecter un lien vers le back-office ou une clé exposée, ce qui permet d'agir immédiatement en cas d'erreur de manipulation - comme un copier-coller ou un glisser-déposer malheureux dans le back-office d'un marchand.
À l'inverse, WordPress centralise une grande quantité de données, y compris des éléments sensibles, dans une seule table : wp_options. Cette approche complexifie les audits, en particulier lorsqu'il s'agit de localiser des secrets dissimulés dans des contenus sérialisés ou transformés (comme en base64).
La lisibilité du modèle de données joue ici un rôle essentiel dans la sécurité PrestaShop, en facilitant la détection des fuites.
Les XSS de catégorie 1, selon la classification du projet OWASP Core Rule Set (CRS), correspondent à des entrées contenant la balise <script>.
PrestaShop les bloque nativement grâce à son ORM legacy, qui applique automatiquement strip_tags() sur les champs texte lors de la sauvegarde.
Résultat : les XSS type 2 (Stored XSS - XSS stockée) de catégorie 1 sont neutralisées dès leurs enregistrements, avant même d'atteindre une quelconque vue dans le backoffice.
Les XSS de catégorie 2, qui consistent à détourner un événement utilisateur (ex : onmouseover, onclick) sans balise <script>, sont également neutralisées dans la plupart des cas grâce à des protections simples et bien intégrées.
L'implémentation défensive de l'ORM constitue un socle solide pour la sécurité PrestaShop face aux attaques XSS classiques.
PrestaShop se distingue par une excellente hygiène dans la structuration de son arborescence, aussi bien dans le cœur que dans les modules. Cette rigueur facilite grandement le blindage applicatif, également appelé hardening, notamment dans les environnements à forte contrainte de sécurité (shops générant plus d'un million d'euros par an).
Le code source natif suit des conventions claires : pas de fichiers exécutables qui traînent à la racine, séparation nette entre les ressources publiques (/themes, /modules, etc.) et les éléments critiques (/classes, /controllers, /src).
Un autre aspect bien pensé est qu'aucun appel natif de la solution (contrairement à d'autres solutions comme Magento) n'entre en conflit avec le blindage applicatif des racines pour paralyser les appels à des fichiers index.php implicites. Cela facilite la lutte contre les charges malveillantes camouflées.
Résultat : il devient possible de mettre en place un blindage renforcé sans heurter le fonctionnement applicatif, ce qui réduit significativement la surface d'attaque - notamment les risques liés aux backdoors dotées d'I/O à haute entropie (article à venir sur la manière dont certains réseaux criminels professionnels assurent la persistance des compromissions).
Pour les plus techniques d'entre vous : lorsque vous appelez l'URL suivante www.touchweb.fr/css/test/, le frontend (Apache2) interprète cela comme un appel implicite à www.touchweb.fr/css/test/index.php, si l'arborescence existe. La mise en place d'un blindage applicatif pour renforcer les racines consiste à paralyser totalement ce type de pattern sur les répertoires (et sous répertoires !) d'assets publics tels que /css/, /js/, /themes/, etc.
PrestaShop offre une base technique remarquable d'un point de vue DevSecOps, facilitant le déploiement de pare-feux applicatifs (WAF) conformes à l'état de l'Art.
Son architecture modulaire, la séparation claire des responsabilités et la rigueur de son ORM en font une solution robuste et naturellement sécurisable par une infogérance PrestaShop disposant de véritables compétences DevSecOps.
En résumé, PrestaShop est l'un des CMS les plus sécurisables du marché. La sécurité PrestaShop tire sa force d'un design réfléchi, d'une architecture lisible, de la maturité de son écosystème et à la sagesse de ses concepteurs.