Sécurité PrestaShop : ce que nous faisons pour vous, ce que vous devez faire

Boutique déjà touchée ? Urgence : boutique PrestaShop piratée · 09 72 03 59 17

Une boutique PrestaShop encaisse des paiements, et c’est d’abord ça qu’un attaquant vient chercher. Le 12 février 2026, PrestaShop a alerté les marchands : un script glissé dans le fichier head.tpl du thème remplaçait les vrais boutons de paiement par des faux. L’alerte a été relayée par 202 ecommerce.

La sécurité PrestaShop se joue sur trois couches : l’hébergement repousse les attaques, la maintenance suit les failles publiées et applique les correctifs, et si quelque chose passe quand même, on réagit selon une procédure déjà rodée. Pour chaque couche, nous détaillons ce que nous faisons, ce qui reste à votre charge, puis la checklist 2026 en 18 points.

Trois couches pour protéger une boutique PrestaShop : l’hébergement arrête scanners et exploits connus, la maintenance ferme les failles et sauvegarde, la réaction limite les dégâts.

<a href="https://cyberial.fr/securite-prestashop/"><img src="https://cyberial.fr/wp-content/uploads/securite-prestashop-3-couches-protection.png" alt="Les 3 couches de protection d'une boutique PrestaShop" /></a><p>Source : <a href="https://cyberial.fr/securite-prestashop/">Sécurité PrestaShop : les 3 couches de protection</a> - CYBERIAL</p>

Par où entrent les attaquants sur une boutique PrestaShop

Quatre portes reviennent, dans les avis de sécurité publiés comme dans les boutiques que nous analysons.

• Un module vulnérable ou abandonné. Friends of Presta publie les failles des modules tiers : en 2026, une injection SQL sans authentification dans Advanced Popup Creator, ou la faille d’un module de transport dont l’éditeur a disparu, qui n’a aucun correctif et impose de supprimer le module (détails plus bas).
• Un cœur non corrigé. Le 18 août 2026, PrestaShop 8.2.8 et 9.1.5 ont corrigé cinq failles, dont trois de gravité élevée. L’une d’elles touche aussi les 1.7, qui ne reçoivent plus de correctifs.
• Des identifiants volés. Selon ZATAZ (21/08/2024), 5 063 accès à des boutiques PrestaShop étaient mis en vente à 100 $ pièce. En août 2026, nous avons analysé une boutique qui n’était pas chez nous : aucun module en cause, mais le mot de passe d’un compte administrateur, utilisé depuis l’étranger. Le module de paiement avait ensuite été modifié pour envoyer les clients vers un faux domaine.
• Les modules nulled (copies non officielles) et les zones oubliées. Un module payant récupéré gratuitement sur un site tiers peut embarquer n’importe quel code. S’y ajoutent les restes : dossier install/ jamais supprimé, vieux modules.old, fichiers de test phpunit oubliés dans un module (CVE-2017-9841, présente dans ps_facetedsearch de la 2.2.1 à la 3.4.1).

Un pare-feu seul ne ferme complètement aucune de ces portes : avec un mot de passe volé, l’attaquant se connecte au back-office comme vous.

Couche 1 : l’hébergement qui répond aux attaques

Cette couche s’applique aux boutiques hébergées sur nos serveurs. Elle agit avant que la requête n’atteigne PrestaShop, et une IP qui insiste finit bannie.

• Cloudflare devant la boutique, avec ses règles gratuites, et un serveur qui n’accepte que le trafic venu de Cloudflare. Ce verrou n’est pas en place sur nos serveurs PrestaShop 1.6.
• Des pages leurres (honeypots) : faux phpMyAdmin, faux Adminer, faux phpunit, et un piège sur l’exploit de la faille ps_facetedsearch. L’adresse IP qui s’y aventure est bannie 7 jours dès la première tentative.
• Les scanners de failles bannis en 1 à 3 secondes. Une IP qui sonde plusieurs boutiques rejoint une liste de blocage, revue chaque semaine.
• Notre pare-feu applicatif (WAF) : patchs virtuels des failles connues, serveur durci, back-office verrouillé. Le détail juste en dessous.
• Un scan d’intégrité chaque nuit. Les fichiers du cœur sont comparés aux fichiers officiels et passés aux signatures de codes malveillants. Un écart déclenche une alerte immédiate.

Notre pare-feu applicatif (WAF) PrestaShop

Sur nos serveurs, chaque boutique passe derrière un pare-feu applicatif (WAF) que nous écrivons et maintenons nous-mêmes, pour PrestaShop. Il agit au niveau du serveur web et de PHP, avant que PrestaShop ne lise la requête : une attaque arrêtée à cet étage ne touche ni le code de la boutique ni sa base de données.

• Des patchs virtuels des failles connues. Quand une faille est publiée sur le cœur ou sur un module, une règle reconnaît la requête qui l’exploite et la bloque, en attendant la mise à jour et en plus d’elle.
• Un serveur durci. Aucun script ne peut s’exécuter dans les dossiers d’images, de téléchargement, de cache ou de fichiers temporaires, ni dans js/ : un fichier piégé déposé par une faille y reste inerte. Les fonctions PHP qui permettent de lancer des commandes sur le serveur sont désactivées, les requêtes malformées sont rejetées avant d’atteindre PHP, et les bases de données sont sur un réseau privé.
• Des versions invisibles. Les fichiers qui trahissent la version exacte d’un module (config.xml, scripts de mise à jour, journaux, notes de version) sont fermés au public. Un robot ne peut plus savoir, en quelques requêtes, quelle faille tenter sur votre boutique.
• Un back-office qui ne se laisse pas modifier, sur activation. Le serveur refuse depuis le back-office l’installation, la mise à jour, la suppression ou le dépôt de modules et de thèmes, même pour un super-administrateur. Un mot de passe volé ne suffit plus à déposer une porte dérobée : ces opérations passent par nous.
• Des pièges qui bannissent. Les pages leurres et le bannissement des scanners décrits plus haut, avec une liste de blocage commune à tous nos serveurs.

Et Cloudflare ? Il filtre en amont, mais en offre gratuite avec un jeu de règles réduit et une seule règle de limitation de débit ; les règles OWASP et ses règles gérées complètes sont réservées aux offres payantes. Surtout, aucun pare-feu générique, celui de Cloudflare comme celui d’un hébergeur, ne connaît la faille publiée la semaine dernière sur l’un de vos modules. C’est pour cela que nous écrivons nos propres règles.

Sur nos serveurs, nous déployons des correctifs de sécurité maison et des patchs virtuels, testés d’abord sur une copie, avec sauvegarde et retour arrière automatique. Pour des boutiques restées en 1.7.8, nous avons rétroporté plusieurs correctifs du cœur, par exemple celui de CVE-2026-44212 . Le 3 juin 2026, nos boutiques hébergées étaient déjà protégées de la faille ps_facetedsearch le jour de l’avis (voir la couche 3).

Inclus, sans pack à acheter. Ce WAF fait partie de l’hébergement PrestaShop sécurisé, dès 30 € HT/mois en option de la maintenance. Pas de « pack sécurité » facturé à part.

Couche 2 : mises à jour de sécurité et veille des failles

La deuxième couche suit votre boutique, quel que soit l’hébergeur. C’est ce que couvre la maintenance préventive PrestaShop.

• Veille de chaque module installé. Vos modules sont comparés aux failles publiées dans les bases OSV et Friends of Presta. Chaque alerte est revérifiée à la main avant d’agir.
• Des mises à jour testées sur une copie. Sauvegarde, copie de la boutique, test du parcours d’achat, comparaison visuelle des pages, puis mise en production. Le retour arrière est testé lui aussi.
• Les mises à jour mineures du cœur incluses. Pour les boutiques en hébergement et maintenance chez nous, les versions mineures de PrestaShop (par exemple de 8.2.7 à 8.2.8) sont appliquées sans supplément, avec la même procédure testée. Le passage à une nouvelle version majeure, de 8 à 9 par exemple, est une migration à part.
• Des sauvegardes quotidiennes chiffrées, stockées hors du serveur et gardées 30 jours ; deux par jour pour les boutiques hébergées chez nous. Restauration complète en 1 h environ, durée mesurée en test.
• Une surveillance toutes les 30 secondes. Une panne de 5 minutes déclenche une alerte à l’équipe. Sur nos serveurs, une alerte part aussi si aucune sauvegarde n’a été faite depuis 26 h, et 14 jours avant l’expiration du certificat SSL.

« Je fais les mises à jour moi-même. » Très bien, si vous les testez sur une copie. Reste le cas où il n’y a rien à mettre à jour, comme pour un module abandonné par son éditeur : encore faut-il le savoir, puis remplacer ou supprimer le module. La veille de la maintenance le signale.

Audit de sécurité des modules

Toutes les failles ne sont pas publiées. Sur les boutiques que nous hébergeons, nous lisons aussi le code des modules tiers que nous installons ou qui posent question, et nous y avons déjà trouvé des failles non publiques.

Couche 3 : la réaction

Le 3 juin 2026, PrestaShop a publié une faille notée 10 sur 10 dans ps_facetedsearch, le module natif de navigation à facettes : exécution de code à distance, sans compte. Le jour de l’avis, nos clients ont reçu un e-mail. Pour les boutiques hébergées chez nous, il précisait : « notre pare-feu vous protège déjà » ; la règle était en place avant l’envoi. Le correctif définitif a suivi, version par version.

Même réflexe le 30 avril 2026, au lendemain de la divulgation de la faille Linux « Copy Fail » : clients hébergés prévenus, mesure de protection prévue pour la nuit même, aucune action demandée de leur côté.

Si une boutique est compromise : nos 5 étapes

1. Scan et mise en quarantaine. Les fichiers suspects sont déplacés, jamais supprimés : ce sont vos preuves.
2. Lecture des logs, pour trouver par où l’attaquant est entré.
3. Durcissement contre ce vecteur, pour qu’il ne serve pas deux fois.
4. Recherche des autres failles de la boutique, et durcissement.
5. Rapport écrit, et aide à la notification à la CNIL si des données personnelles sont touchées (72 h).

Le nettoyage coûte 150 € HT, prix fixe, et il est offert avec la maintenance. Le détail est sur la page boutique PrestaShop piratée. Urgence par téléphone : 09 72 03 59 17, réponse en moins d’une heure, 7j/7, de 8 h à 22 h.

Risque par risque : ce qui l’arrête, et qui s’en charge

La maintenance à 69 € HT par mois ne couvre pas tout : le tableau indique qui prend en charge chaque risque. Trois étiquettes : Maintenance (69 € HT/mois), Hébergement (dès 30 € HT/mois, en option), Vous (à votre charge).

Sécuriser PrestaShop : la checklist du marchand (18 points)

Même avec un mainteneur, vos accès, le choix des modules et le mode de paiement restent de votre ressort. Avancez point par point, et reprenez la liste avant chaque temps fort, comme le Black Friday sur PrestaShop. Avec notre maintenance, les quatre points marqués « fait par la maintenance » sont déjà couverts.

Accès

• Un compte par personne, avec le profil minimum ; ceux des anciens salariés et prestataires supprimés (Paramètres avancés > Équipe ; Administration > Employés en 1.6).
• Des mots de passe longs et uniques ; en 8 et 9, une politique de mot de passe imposée (Paramètres avancés > Sécurité).
• Une double authentification sur le back-office, via un module : PrestaShop n’en a pas de native, une demande de modification est en préparation pour la 9.3.
• Le dossier admin renommé (PrestaShop le fait à l’installation) et protégé en plus par un mot de passe serveur ou une liste d’IP, à demander à votre hébergeur.
• Les clés Webservice inutilisées supprimées, les autres limitées aux droits utiles (Paramètres avancés > Webservice ; « Service web » sur certaines 1.6).

Modules et mises à jour

• Le cœur à jour : 8.2.8, 9.1.5 ou 9.2.0 au 01/10/2026 ; votre version s’affiche dans Paramètres avancés > Informations. En 1.7, plus aucun correctif officiel. Fait par la maintenance, en 8 et 9, dans votre branche (en 1.7, le passage à 8 ou 9 est une migration, prévue à part).
• Chaque module comparé aux avis de sécurité (Friends of Presta, GitHub) au moins une fois par mois. Fait par la maintenance.
• Les modules inutilisés désinstallés, puis supprimés : un module désinstallé laisse ses fichiers. Dans Modules > Gestionnaire de modules, cochez en désinstallant « Optionnel : supprimer le dossier du module après la désinstallation » ; un module déjà désinstallé se supprime par l’action Supprimer (1.6, 8 et 9) ou par FTP (1.7).
• Des modules achetés sur Addons ou chez l’éditeur, jamais de module nulled.
• Chaque mise à jour testée sur une copie, après une sauvegarde complète. Fait par la maintenance.

Serveur et fichiers

• Le dossier install/ supprimé ; aucun fichier de test (phpunit) ni vieille copie (modules.old) en ligne, à vérifier par FTP ou le gestionnaire de fichiers de votre hébergeur.
• Le mode debug désactivé en production (Paramètres avancés > Performances ; en 1.6, vérifiez par FTP que config/defines.inc.php contient _PS_MODE_DEV_ à false, et faites la modification sur une copie du fichier).
• Le SSL activé sur toutes les pages : « Activer le SSL » et, jusqu’en 8, « Activer le SSL sur tout le site » (Paramètres de la boutique > Paramètres généraux ; Préférences > Générales en 1.6). Si « Activer le SSL » affiche un lien au lieu d’un interrupteur, cliquez sur ce lien de vérification HTTPS ; s’il échoue, demandez un certificat à votre hébergeur.
• Une version de PHP encore maintenue (visible dans Paramètres avancés > Informations). PrestaShop 8.0 à 8.2 s’arrête à PHP 8.1, en fin de vie depuis le 31/12/2025.

Paiement et sauvegardes

• Un paiement sur la page du prestataire ou dans son iframe, plutôt qu’un formulaire intégré (voir pourquoi).
• Le fichier themes/votre-thème/templates/_partials/head.tpl (en 1.6, themes/votre-thème/header.tpl) et les scripts du tunnel de commande contrôlés chaque mois, par FTP ou le gestionnaire de fichiers de votre hébergeur. Un script que vous n’avez pas ajouté est suspect : ne supprimez rien et appelez le 09 72 03 59 17.
• Une commande test en navigation privée chaque mois, jusqu’à la page du prestataire : vérifiez l’adresse affichée.
• Des sauvegardes hors du serveur (fait par la maintenance), et une restauration déjà testée.

Paiement et obligations : PCI DSS et RGPD

Votre moyen de paiement change ce que vous devez prouver.

• Redirection vers la page du prestataire. Le client saisit sa carte ailleurs que chez vous. C’est le cas le plus simple pour le questionnaire PCI.
• Champs du prestataire en iframe sur votre page. Vous relevez du questionnaire SAQ A. Le 30/01/2025, le PCI SSC en a retiré les exigences 6.4.3, 11.6.1 et 12.3.1, avec effet au 31/03/2025. Un critère reste pourtant à remplir : votre page ne doit pas être exposée à des scripts capables d’atteindre le paiement. Vous le démontrez en contrôlant ces scripts, ou votre prestataire le confirme.
• Formulaire intégré, quand c’est le JavaScript de votre page qui transmet la carte. On passe en SAQ A-EP. Depuis le 31/03/2025, l’exigence 6.4.3 (inventaire et intégrité de chaque script de la page de paiement) et l’exigence 11.6.1 (détection des modifications, au moins chaque semaine) s’appliquent.

L’iframe allège le questionnaire, mais dans les trois cas un script ajouté peut remplacer vos boutons, comme en février 2026 via head.tpl. Pour savoir dans quel cas vous êtes, passez une commande test : si l’adresse change au moment de saisir la carte, c’est une redirection ; sinon, demandez à votre prestataire.

Côté RGPD, l’article 32 vous demande une sécurité adaptée au risque. En cas de fuite de données, l’article 33 impose de notifier la CNIL « dans les meilleurs délais et, si possible, 72 heures au plus tard » après en avoir pris connaissance (texte sur le site de la CNIL). Cette notification vous revient, en tant que responsable de traitement. En sous-traitant, nous vous prévenons dans les meilleurs délais et nous vous aidons à la remplir.

Si le risque est élevé pour vos clients, l’article 34 impose aussi de les informer. La CNIL résume : « En cas de doute, notifiez à la CNIL qui vous indiquera s’il est nécessaire d’informer les personnes ». Le reste des obligations est détaillé dans notre page RGPD PrestaShop.

Failles PrestaShop 2026 : les CVE à connaître (1.7, 8 et 9)

Mis à jour le 02/10/2026. Les failles PrestaShop publiées depuis fin 2025 qui comptent pour une boutique en production, du plus récent au plus ancien : le numéro CVE quand il existe, ce qui est touché (cœur 1.7, 8 ou 9, ou module) et la version qui corrige, s’il y en a une. Les avis de gravité faible, ou sans objet pour une boutique française, ne sont pas repris.

Reste à croiser chaque avis avec les versions de vos modules : c’est la veille incluse dans la maintenance.

Questions fréquentes sur la sécurité PrestaShop

Confier la sécurité de votre boutique

Laissez l’adresse de votre boutique pour confier sa sécurité PrestaShop à notre maintenance : 69 € HT/mois, sans engagement, hébergement en option dès 30 € HT/mois, nettoyage offert en cas de compromission. En urgence, appelez le 09 72 03 59 17 : réponse en moins d’une heure, 7j/7, de 8 h à 22 h.