Audit sécurité PrestaShop : méthodologie, livrables et durcissement

Table des matières :

Dans cet article, on parle d’un audit sécurité PrestaShop orienté résultats : un périmètre clair, des preuves reproductibles, des livrables actionnables et un durcissement qui tient compte des contraintes e‑commerce (conversion, paiements, SEO, ops). L’objectif n’est pas de produire une liste générique, mais de réduire le risque réel sur votre stack (core, modules, thème, infra et intégrations).

Cadrer un audit sécurité PrestaShop : périmètre, hypothèses et modèle de menace

Un audit sécurité PrestaShop utile commence par figer des hypothèses testables : version exacte du core, version PHP, mode d’hébergement (mutualisé/VPS/Kubernetes), présence d’un CDN/WAF, et surtout la liste des intégrations (paiement, ERP, tracking, search, pixels). Sans ça, vous allez produire un rapport « générique OWASP » impossible à remédier. Pour les exemples ci-dessous, je pars sur PrestaShop 8.1.x (mix legacy + Symfony dans le back‑office) avec PHP 8.2 et MariaDB, mais la méthodo s’applique aussi à 1.7.8+ et 9.x (à ajuster selon composer.lock, modules et stack).

Ensuite, formalisez le périmètre technique (ce qui est audit éligible) et le périmètre business (ce qui doit être protégé). En e‑commerce, les actifs critiques sont rarement « la home » : ce sont le checkout, le compte client, le back‑office, les webhooks, les crons, le Webservice PrestaShop et les endpoints exposés par des modules. Sur PrestaShop, l’erreur classique est d’ignorer les routes legacy (paramètres en GET, contrôleurs peu typés) et les overrides historiques ; c’est exactement là que se logent les vulnérabilités persistantes.

Pour éviter un cadrage trop abstrait, posez noir sur blanc les types de données réellement manipulés. Dans une boutique standard, on retrouve vite : identité et coordonnées (PII), historique de commandes, adresses de livraison, e‑mails, parfois date de naissance, et des identifiants techniques (tokens, webhooks, clés API). Même si vous ne stockez pas de données carte (ce qui est généralement le cas quand vous passez par un PSP), une compromission peut suffire à exfiltrer des comptes clients et déclencher du phishing à grande échelle.

Enfin, posez un modèle de menace pragmatique. L’OWASP Top 10 sert surtout de base de couverture (authN/authZ, injection, gestion de session, exposition de données sensibles, etc.) : OWASP Top 10. Traduction opérationnelle : votre audit doit couvrir au minimum l’authN/authZ, l’injection (SQL/OS), la gestion de session, l’exposition de données sensibles, les failles de logique métier (fraude, abus de promotions), et la supply chain (modules, dépendances composer/npm).

Un format simple qui marche bien pour un modèle de menace “audit” consiste à relier actifs ↔ scénarios ↔ contrôles. Exemple (à adapter à votre contexte) :

Actif	Scénario d’attaque réaliste	Impact business	Contrôles attendus / tests
Back‑office	Credential stuffing / vol de session / accès admin non filtré	Prise de contrôle, fraude, exfiltration	2FA, filtrage IP/VPN, cookies sécurisés, logs d’admin, rotation des mots de passe
Checkout	Manipulation de prix/remise, bypass validation panier	Perte directe de CA	Tests de logique métier, validation côté serveur, contrôles d’intégrité, anti‑automation
Webhooks & callbacks paiement	Endpoint trop permissif ou non authentifié	Commandes “payées” sans paiement	Signature HMAC, allowlist IP PSP, anti‑replay, journalisation
Webservice PrestaShop	Clé trop large, non rotée, exposée	Lecture/écriture sur clients/commandes	Scoping des ressources, rotation, restrictions IP, détection d’abus
Modules front	Contrôleur module non protégé (IDOR/SQLi/XSS)	Exfiltration, défiguration, fraude	Revue statique + tests dynamiques, validation/échappement, ACL

Pré‑requis et risques à annoncer dès le kick‑off

L’audit ne se fait pas « en production sans impact » par défaut. La moindre campagne de fuzzing peut déclencher des verrous applicatifs, saturer PHP‑FPM, remplir var/log/ et faire tomber un checkout. Prévoyez : un environnement de pré‑prod représentatif (mêmes modules, mêmes configs), un export anonymisé si possible, et une fenêtre de tests en heures creuses si certaines vérifications doivent toucher la prod.

Côté accès, exigez a minima : un compte back‑office avec permissions limitées, un accès SFTP/SSH en lecture, un dump DB en lecture (ou un user SQL read‑only), et la liste complète des clés/API utilisées (paiement, CRM, ERP, shipping). Sans inventaire des secrets, impossible d’évaluer le risque de fuite et l’exploitabilité.

Pour rendre le kick‑off “exécutable”, vous pouvez aussi demander une fiche d’architecture très courte (1 page) avec : origines (CDN/WAF/origin), où résident les médias, comment tournent les crons, et où sont envoyés les logs. Ce document évite la moitié des malentendus, notamment sur les flux sortants (API transporteurs, tracking, emailing) et sur les composants parfois oubliés (moteur de recherche, Redis, worker, back‑office sur un sous‑domaine).

Enfin, clarifiez la règle du jeu : tests d’intrusion autorisés ou non, collecte de PII autorisée ou non, et méthode de preuve (captures, requêtes, hashes). Si vous avez déjà un plan de réponse à incident, alignez les procédures (sinon, vous allez “découvrir” une compromission sans savoir contenir). Voir la méthodo de containment dans : Sécurité PrestaShop : plan de réponse à incident et containment immédiat.

Cartographier la surface d’attaque : exposition réseau, DNS, routes et accès admin

La première brique « audit » n’est pas du code : c’est l’exposition réelle. Beaucoup de boutiques ont plusieurs frontaux (www, preprod, admin, API, endpoints legacy) et plusieurs origines (serveur direct + CDN + back‑office sur sous‑domaine). Faites une cartographie DNS/HTTP : A/AAAA/CNAME, TTL, enregistrements oubliés (ex : old. / test. / staging.). Le DNS est un vecteur de shadow IT ; sur OVHcloud par exemple, une zone mal tenue et des TTL incohérents compliquent aussi les bascules de remédiation. Référence : Zone DNS OVHcloud : propagation, TTL et bonnes pratiques de configuration.

Sur la couche HTTP, l’objectif est simple : lister ce qui répond, ce qui redirige, et ce qui fuit de l’info (headers, pages d’erreur, endpoints de debug). Concrètement : scan de ports (80/443 mais aussi 8080/8443), découverte des vhosts, contrôle TLS (versions, suites, HSTS), et vérification des headers de sécurité (CSP, X‑Frame‑Options, Permissions‑Policy). PrestaShop ne fournit pas de durcissement « par défaut » : si vous n’avez pas une politique CSP et un encodage contextuel discipliné, le risque XSS dépend intégralement de la qualité des thèmes/modules. Pour une checklist XSS/CSP orientée PrestaShop : XSS : checklist de durcissement PrestaShop, CSP et encodage contexte.

Pour éviter de “rater” des surfaces exposées, ajoutez quelques contrôles très concrets :

Fichiers sensibles accessibles : .env, app/config/parameters.php ou config/parameters.php (selon versions), dumps .sql, .zip, répertoires .git/, exports de modules, phpinfo(), endpoints de debug.
Répertoires d’assets exécutables : vérifiez qu’un upload ne peut pas être interprété côté serveur (PHP, phtml, etc.).
Pages d’erreur & stack traces : un 500 verbeux en prod donne souvent la version exacte du core, des modules et parfois des chemins système.
“Environnements fantômes” : une pré‑prod indexable, un admin sur un sous‑domaine prévisible, un ancien domaine pointant encore sur un serveur.

Le point PrestaShop à traiter très tôt : l’accès back‑office. Vérifiez que le répertoire /admin est renommé (et pas exposé via redirection ou leak dans robots.txt), que /install est supprimé, et que les accès admin sont filtrés (IP allowlist via reverse proxy, VPN, ou au minimum 2FA si disponible via module). Ajoutez une vérification systématique des endpoints de modules accessibles sans authentification : beaucoup exposent des contrôleurs front (module/{name}/{controller}) oubliés, ou des callbacks de paiement avec validation trop permissive.

Mini‑scénario typique vu en boutique : un sous‑domaine staging. garde des identifiants admin faibles “pour tester”, est indexé, et réutilise le même secret de cookie/session que la prod (ou un accès DB partagé). Même si la prod est filtrée, la pré‑prod devient une rampe d’accès pour comprendre la structure et préparer une attaque ciblée.

Audit applicatif PrestaShop : core, modules, overrides et logique métier

La réalité d’un audit sécurité PrestaShop, c’est 80% de modules + overrides + thème, et 20% de core. Le core évolue, reçoit des correctifs, et ses patterns sont connus ; vos développements sur‑mesure, eux, restent en place des années. Priorité : inventorier modules/, override/, themes/, et construire une matrice « provenance / mainteneur / dernière release / surface exposée ». Si vous avez une boutique qui a traversé 1.6 → 1.7 → 8, vous aurez presque toujours des restes (classes override qui ne s’appliquent plus, hooks obsolètes, contrôleurs legacy jamais relus).

Une matrice d’inventaire (même “simple”) rend l’audit beaucoup plus rapide et aide à prioriser :

Élément	Type	Exposé côté front ?	Exposé côté BO ?	Données manipulées	Criticité pressentie
Module paiement	Module	Oui (return/callback)	Oui	Commandes, statuts	Élevée
Connecteur ERP	Module	Parfois (webhook)	Oui	Clients, commandes	Élevée
Thème / overrides	Thème/override	Oui	Non	Affichage, panier	Moyenne à élevée
Module “marketing”	Module	Oui	Oui	PII, tracking	Moyenne

Sur le plan technique, l’audit applicatif se déroule en deux flux complémentaires : revue statique (SAST) et revue dynamique (DAST + tests manuels). En statique, cherchez en priorité : concaténations SQL, usage douteux de Db::getInstance()->executeS() avec variables non castées, appels directs à Tools::getValue() sans validation, et sorties HTML non échappées. Ajoutez le spectre PHP “moderne” : désérialisation non maîtrisée, appels unserialize()/__wakeup()/__destruct(), et chaînes d’objets exploitables. Pour cadrer les risques concrets : Désérialisation PHP : bonnes pratiques pour prévenir l’injection d’objets.

Points d’attention PrestaShop souvent rentables en SAST (parce qu’ils réapparaissent dans les modules tiers) :

Contrôleurs front de modules : vérification CSRF absente, contrôles d’accès implicites, paramètres d’ID non liés au client connecté.
Templates Smarty : variables affichées sans échappement, inclusion de morceaux HTML issus de paramètres BO, et sur‑confiance dans des champs “admin” (un compte BO compromis suffit).
Uploads : champs “image”, import CSV, pièces jointes, ou connecteurs marketplace. Le risque n’est pas seulement l’extension, mais le parcours complet (stockage, renommage, lecture, traitement).

En dynamique, ciblez l’authZ et la logique métier. Les failles les plus rentables en e‑commerce ne sont pas toujours des injections : ce sont des contournements de droits (IDOR), des bypass de prix/remise, ou des endpoints de mise à jour de panier mal protégés. L’OWASP en parle sous le terme « Broken Access Control » ; côté PrestaShop, ça se matérialise souvent via un contrôleur module acceptant un id_order/id_customer sans vérifier l’appartenance. Pour une approche structurée : Broken access control : prévenir IDOR et élévation de privilèges.

Quelques tests manuels “logique métier” qui valent le coup (et qui sont mesurables) :

Paniers : modification concurrente (2 onglets), changement de devise, forçage de quantités négatives/énormes, suppression de lignes, ajout d’un produit désactivé.
Promotions : cumul non prévu (codes + règles panier), réutilisation d’un code “unique”, bypass de conditions (pays, transporteur, minimum).
Commande : accès direct à la page détail avec un autre id_order, tentative d’annulation/remboursement via endpoint module, re‑jeu de callback de paiement.
Compte client : reset password (énumération), changement d’adresse “par ID” via requête.

Un chapitre à isoler : API et Webservice. Le Webservice PrestaShop est pratique, mais ses clés donnent souvent accès à trop de ressources et restent valides indéfiniment. Auditez : droits par ressource, rotation, restrictions IP, et journalisation. Deux références internes pour cadrer le sujet : API Webservice PrestaShop : accès CRUD, authententification et bonnes pratiques et, plus généraliste mais indispensable, API : sécuriser apikey, limiter le débit et renforcer la conformité.

Audit infra et runtime : serveur web, PHP, permissions, base de données, secrets

Même avec un code propre, une boutique tombe sur des défauts d’infra “banals” : répertoires world‑writable, backups accessibles par HTTP, creds en clair dans des fichiers versionnés, et services adjacents (Redis, Elasticsearch, Meilisearch) exposés. Le durcissement commence par des invariants : permissions minimales (pas de 777), séparation des users (déploiement ≠ runtime), désactivation des index de répertoires, et interdiction d’exécuter du PHP dans img/, upload/, download/ et tout répertoire d’assets. Sur un serveur traditionnel, ça se fait via configuration Nginx/Apache ; sur PaaS/CDN, via règles d’edge + origin.

Sur PrestaShop, deux “anti‑patterns” reviennent :

mélange des rôles : le même utilisateur système peut déployer, écrire des fichiers applicatifs et exécuter PHP. Si un upload ou une faille RCE survient, l’attaquant hérite d’un pouvoir trop large.
fichiers de sauvegarde : backup_2024-xx-xx.sql.gz laissé dans public/ ou un répertoire web accessible “temporairement”.

Sur PHP, ne partez pas dans le cargo‑cult (ex : disable_functions énorme qui casse des modules) : partez des menaces. Protégez l’exécution (open_basedir si pertinent), limitez la surface d’upload (taille, MIME, antivirus asynchrone), et verrouillez les erreurs (pas d’affichage en prod, logs centralisés). L’OPcache et la performance ne sont pas que du confort : un PHP‑FPM saturé rend votre WAF aveugle (timeouts) et augmente la probabilité de contournements. Pour la partie perf‑runtime, voir : PHP OPcache : paramètres recommandés pour optimiser les performances.

Côté base de données, l’audit doit vérifier la séparation des privilèges (un user applicatif ne devrait pas avoir SUPER, ni pouvoir créer des users), le chiffrement en transit (TLS MySQL si réseau partagé), et la politique de sauvegarde/restauration (RPO/RTO documentés). Ajoutez l’audit des stores de secrets : variables d’environnement, coffre (Vault/Secrets Manager), ou fichiers. Dans un contexte PrestaShop, vérifiez aussi les emplacements “historiques” où l’on retrouve des secrets (selon versions et déploiements) : fichiers de config, scripts de cron, modules connecteurs (où des clés API sont parfois hardcodées), et exports d’assistance (archives envoyées à un prestataire).

Si vous opérez en conteneurs, alignez aussi les images sur un benchmark (CIS/DISA) plutôt que d’improviser. Référence utile pour un cadre : DISA : sécuriser les images conteneurisées selon le guide officiel.

Enfin, ne négligez pas les services annexes très fréquents autour de PrestaShop : Redis, moteurs de recherche, queues. Redis exposé ou mal authentifié est un classic (vol de session, RCE selon contexte). Si Redis est dans votre stack, faites un audit d’exposition et de config : Redis sur Linux : installation, configuration et sécurisation production.

Pour ajouter un peu de contexte “terrain” en France/UE : les boutiques hébergées chez des acteurs courants (OVHcloud, Scaleway, AWS eu‑west, etc.) combinent souvent reverse proxy, firewall managé et quelques services “à côté” (object storage, base managée, CDN). L’audit infra doit donc couvrir la cohérence des règles entre ces couches (ex : un back‑office filtré au CDN mais accessible en direct sur l’origin).

Livrables d’audit : ce qui est réellement actionnable (et ce qui ne l’est pas)

Un « rapport d’audit » n’a de valeur que s’il se transforme en tickets de remédiation priorisés, testables et ré‑auditables. Le minimum viable côté livrables : (1) une synthèse risque (pour arbitrage CTO), (2) un registre de vulnérabilités avec preuves, (3) un plan de correction par lots (quick wins vs refactors), (4) une checklist de durcissement reproductible (IaC/Ansible si possible), et (5) une stratégie de validation (tests + re‑scan). Sans ces éléments, l’audit devient un PDF qui finit en pièce jointe.

Structure recommandée pour chaque finding (format “ingénierie”, pas storytelling) : ID, composant (core/module/thème/infra), vecteur (endpoint + méthode), pré‑requis, pas à pas de reproduction, impact, score (CVSS v3.1/v4.0 ou scoring interne), evidence (requêtes, extraits de code, hashes), correctif (patch, config, mitigations), tests de non‑régression. Pour les vulnérabilités PrestaShop connues, rattachez aux CVE quand elles existent et documentez le delta entre votre instance et le correctif upstream. Exemple de workflow sur une vulnérabilité récente : Sécurité PrestaShop : corriger la CVE-2026-54159 et durcir psfacetedsearch.

Un finding “actionnable” comporte aussi une recommandation testable. Exemple de formulation qui aide :

Mauvais : “Ajouter de la sécurité sur les contrôleurs modules”
Bon : “Sur module/foo/bar, refuser toute requête sans token CSRF + vérifier que id_order appartient à Context::customer ; ajouter un test de non‑régression qui prouve qu’un client A ne peut pas lire la commande du client B.”

Pour donner de la traction au plan, mesurez. En pratique, les équipes qui remédient vite suivent 3 métriques simples : MTTR (mean time to remediate) par criticité, taux de réouverture (correctifs incomplets), et couverture (pourcentage de modules scannés/revus vs total). C’est aussi une exigence implicite de conformité : PCI DSS v4.0 pousse des pratiques de gestion de vulnérabilités et de monitoring continu, et le NIST SP 800‑61r2 rappelle l’importance d’une capacité organisée de réponse à incident (NIST SP 800-61r2). Un audit doit donc produire des artefacts exploitables par l’IT run (supervision, patching, playbooks).

Exemple de lot de livrables (à livrer en dépôt Git interne)

report.md : synthèse + findings
evidence/ : exports Burp, captures, logs, PoC minimal
hardening/ : snippets Nginx/Apache, headers, CSP, règles WAF
remediation-plan.csv : backlog priorisé (owner, effort, deadline)
retest.md : protocole de re‑test + critères d’acceptation

Durcissement post-audit : quick wins PrestaShop et passage au contrôle continu

Le durcissement “post-audit” doit viser des gains rapides sans casser le business. Les quick wins typiques sur PrestaShop : renommer et filtrer l’admin, supprimer /install, fermer l’accès public aux logs et backups, activer HSTS après validation, ajouter des headers de base (au minimum X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy), et imposer des politiques de mots de passe/2FA côté back‑office. Pour le checkout, un WAF bien réglé est un filet utile, mais il ne remplace pas la correction applicative ; et mal réglé il crée des faux positifs qui tuent la conversion. Si vous déployez un WAF, faites-le avec une stratégie de tuning : WAF PrestaShop : réduire les faux positifs et sécuriser le checkout.

Ajoutez à ces quick wins une hygiène souvent “oubliée” mais très rentable :

Cookies : vérifiez Secure, HttpOnly et une politique SameSite compatible avec vos parcours (notamment paiement/iframe si applicable).
Rate limiting : sur endpoints sensibles (connexion, reset password, panier, webhooks), au niveau reverse proxy/WAF quand possible.
Réduction de bruit : désindexer/fermer les environnements non destinés au public, et supprimer les anciennes routes/contrôleurs non utilisés.

Deuxième étape : industrialiser l’hygiène de dépendances. Sur une base moderne (PrestaShop 8/9 + Composer), vous pouvez automatiser : composer audit, contrôle d’intégrité des sources (supply chain, forks), et revue des modules tiers avant déploiement. La compromission par package reste un scénario réaliste (typosquatting, compte éditeur compromis). Côté process, imposez un pipeline de build qui refuse les dépendances vulnérables au‑delà d’un seuil, et documentez les exceptions. Pour cadrer la partie “dépôts officiels” et éviter les forks douteux : PrestaShop GitHub : dépôts officiels, vérification et sécurité anti-forks.

Troisième étape : mettre la sécurité sous observabilité. Si vous ne centralisez pas les logs PHP, Nginx/Apache, MariaDB et JavaScript, vous n’aurez ni détection, ni reconstitution. PrestaShop expose déjà beaucoup de signaux (erreurs, paniers anormaux, pics de requêtes), mais il faut les capter et alerter proprement : PrestaShop monitoring d’erreurs : logs PHP, MySQL, JavaScript et alertes e-mail. L’audit sécurité devient alors un cycle : scan → remédiation → re‑test → monitoring → incident response.

Enfin, planifiez le patch management comme un produit, pas comme une opération “quand on a le temps”. Sur PrestaShop, les mises à jour core/modules ont des effets de bord (compatibilité thème, overrides, modules paiement). Si vous ne testez pas, vous restez bloqué sur des versions vulnérables. Utilisez une checklist de mise à jour avec sauvegarde, pré‑prod, et plan de rollback : Mise à jour PrestaShop : checklist sauvegarde, pré-production et tests. Le durcissement n’est pas un état final : c’est un compromis maîtrisé entre risque, stabilité, et cadence de livraison.