Hardening des CMS e-commerce : sécuriser PrestaShop et WordPress/WooCommerce

Un module de paiement est installé un vendredi soir. Personne ne l’a relu, parce qu’il « venait d’un éditeur sérieux » et que la boutique tournait bien. Trois semaines plus tard, un script discret glissé dans une page de remerciement copiait les numéros de carte saisis au checkout et les envoyait ailleurs. Aucune alerte, aucun ralentissement, aucune trace visible côté client. La boutique fonctionnait parfaitement. C’est justement le problème : un site compromis ne prévient pas.

Le réflexe naturel, quand on parle de sécurité e-commerce, c’est de penser « pare-feu » et « antivirus ». Mais l’essentiel se joue avant : dans la façon dont le CMS, ses modules, son serveur et ses comptes sont configurés. Durcir un site, c’est réduire le nombre de portes qu’un attaquant peut pousser, fermer celles qui ne servent à rien, et verrouiller celles qui restent. Ça ne coûte presque rien comparé à une intrusion, et ça change tout. Voici comment s’y prendre concrètement sur les deux CMS les plus répandus en France : PrestaShop et WordPress/WooCommerce.

Hardening : durcir un site, ce n’est pas le bloquer

Le hardening, ou durcissement, consiste à configurer un système pour qu’il expose le moins de surface possible à une attaque. L’idée tient en une phrase : tout ce qui n’est pas nécessaire au fonctionnement du site est une porte potentielle, donc on le ferme.

Ça ne veut pas dire empiler des outils de sécurité. Un site bardé de plugins « sécurité » mais mal configuré reste vulnérable. Le durcissement, c’est l’inverse de l’accumulation : on retire les modules inutiles, on coupe les fonctions exposées qui ne servent à rien, on restreint les accès au strict minimum, on met à jour ce qui reste. C’est un travail d’hygiène, pas de gadget. C’est la logique des bonnes pratiques de cybersécurité pour les PME, appliquée au terrain e-commerce.

Sur un site marchand, l’enjeu est double. D’un côté la donnée : comptes clients, adresses, historiques de commande, parfois des éléments de paiement. De l’autre le chiffre d’affaires : une boutique hors ligne trois jours après un défacement, c’est de la vente perdue qui ne reviendra pas. Le durcissement protège les deux en même temps.

Le socle commun à tous les CMS e-commerce

Avant les spécificités de chaque plateforme, il y a un socle qui s’applique partout. Si vous ne deviez traiter qu’une seule liste, c’est celle-ci.

• Mettre à jour, vraiment. Le cœur du CMS, les modules, les thèmes, la version de PHP. Une faille publiée sur un composant non corrigé est exploitée en quelques heures par des robots qui scannent le web en continu. La mise à jour n’est pas une corvée optionnelle, c’est la première ligne de défense.
• Activer l’authentification à deux facteurs sur tous les accès d’administration. Un mot de passe volé ne suffit alors plus à entrer.
• Imposer des mots de passe robustes et bannir les comptes génériques type « admin ». Chaque administrateur possède son compte nominatif, avec uniquement les droits dont il a besoin.
• Forcer le HTTPS partout et vérifier les en-têtes de sécurité (voir le tableau plus bas).
• Sauvegarder de façon automatique, régulière et testée, avec au moins une copie stockée hors du serveur de production. Une sauvegarde qu’on n’a jamais essayé de restaurer n’est pas une sauvegarde, c’est un espoir.
• Supprimer ce qui ne sert pas : modules désactivés mais toujours présents, thèmes de démonstration, comptes d’anciens prestataires, fichiers d’installation oubliés.

Ce socle, on l’a vu se vérifier dans la pratique : la plupart des intrusions documentées dans notre anatomie d’une cyberattaque sur un site e-commerce auraient été stoppées net par deux ou trois de ces points appliqués sérieusement.

Les en-têtes HTTP à vérifier en priorité

Les en-têtes de réponse sont les instructions que votre serveur donne au navigateur du visiteur. Bien réglés, ils bloquent des familles entières d’attaques sans aucune ligne de code applicative.

Durcir PrestaShop : les points qui comptent vraiment

PrestaShop est solide quand il est tenu à jour, mais sa richesse fonctionnelle multiplie les zones à surveiller. Les actions de durcissement les plus rentables :

• Renommer le dossier d’administration. Le back-office par défaut est une cible évidente. Un nom imprévisible réduit fortement les tentatives de connexion automatisées.
• Désactiver le mode développeur et l’affichage des erreurs en production. Un message d’erreur verbeux révèle des chemins, des versions et parfois des bouts de requête qui font le bonheur d’un attaquant.
• Verrouiller les permissions de fichiers selon le principe du moindre privilège. Le serveur web ne doit pouvoir écrire que là où c’est strictement nécessaire.
• Auditer chaque module tiers avant installation, et désinstaller (pas seulement désactiver) ceux qui ne servent plus. Les modules sont historiquement le maillon faible : un module abandonné par son éditeur ne recevra jamais de correctif.
• Activer la protection contre le brute force sur la page de connexion et limiter le nombre de tentatives.
• Vérifier les cookies et le token de sécurité pour couper les manipulations d’URL et le rejeu de requêtes.

Le point le plus négligé reste la chaîne des modules. Un cœur PrestaShop parfaitement à jour ne protège en rien d’un module de paiement ou de catalogue vulnérable. Avant d’installer quoi que ce soit, posez-vous trois questions : qui maintient ce module, à quand remonte sa dernière mise à jour, et a-t-il vraiment besoin des droits qu’il demande.

Durcir WordPress et WooCommerce : fermer les portes ouvertes par défaut

WordPress est le CMS le plus répandu au monde, ce qui en fait aussi la cible la plus scannée. Beaucoup de ses portes d’entrée sont ouvertes par défaut pour des raisons de confort, et c’est à vous de les refermer.

• Protéger l’accès à wp-admin et wp-login, par une restriction d’IP quand c’est possible, une limitation des tentatives de connexion et l’authentification à deux facteurs.
• Désactiver l’éditeur de fichiers intégré au tableau de bord. S’il reste actif, un compte admin compromis permet de modifier directement le code du site depuis le navigateur.
• Couper XML-RPC s’il n’est pas utilisé : c’est un vecteur classique d’attaques par force brute et par amplification.
• Limiter l’exposition de l’API REST et l’énumération des utilisateurs, qui permet sinon à un robot de lister vos comptes avant de les attaquer.
• Sécuriser le fichier wp-config (permissions strictes, clés de sécurité uniques) et déplacer ou protéger les fichiers sensibles.
• Réduire le nombre de plugins au strict nécessaire. Chaque extension est du code tiers exécuté sur votre site. Moins il y en a, plus la surface d’attaque est petite, et plus la maintenance est tenable.

WooCommerce ajoute par-dessus la dimension transactionnelle : comptes clients, tunnel de paiement, données de commande. Les mêmes principes s’appliquent, avec une vigilance accrue sur les extensions de paiement et de livraison, qui touchent directement à l’argent et aux données personnelles.

PrestaShop ou WordPress : des philosophies différentes, un même cap

Les deux plateformes ne se durcissent pas exactement de la même manière, mais elles convergent vers le même objectif (si le choix entre les deux se pose encore, notre comparatif PrestaShop ou WooCommerce fait le point). Ce tableau résume les priorités propres à chacune.

La couche serveur et hébergement, trop souvent oubliée

Durcir le CMS sans durcir ce qu’il y a en dessous, c’est blinder la porte d’entrée en laissant la fenêtre ouverte. Le serveur compte autant que l’application.

Quelques mesures qui font la différence : un pare-feu applicatif (WAF) devant le site pour filtrer les requêtes hostiles, un mécanisme de bannissement automatique des adresses qui multiplient les tentatives de connexion, une version de PHP maintenue (pas une version en fin de vie qui ne reçoit plus de correctifs), et une séparation nette entre les environnements de production et de préproduction. Un sous-domaine de staging oublié, indexé par les moteurs de recherche avec un fichier de configuration accessible, est l’une des fuites les plus fréquentes que l’on rencontre.

Enfin, la maintenance n’est pas un état mais un processus. Un site « durci » en janvier ne l’est plus en juin si rien n’a été mis à jour entre-temps. C’est exactement la logique qu’on applique sur les sites que l’on crée et maintient pour nos clients : la même équipe construit et protège, pour qu’un correctif puisse être posé immédiatement.

Surveiller, parce que le durcissement ne suffit pas seul

Le meilleur durcissement ne rend pas un site invulnérable, il le rend plus difficile à attaquer. Il faut donc aussi être capable de voir ce qui se passe. Une intrusion détectée en quelques heures se gère ; la même intrusion découverte trois mois plus tard, après que les données ont fui, devient une crise.

La supervision repose sur deux piliers : la surveillance de l’intégrité des fichiers (pour repérer un fichier ajouté ou modifié à votre insu) et la centralisation des journaux pour détecter les comportements anormaux. C’est précisément le rôle d’un outil comme celui que nous décrivons dans notre article sur la surveillance d’un site web avec Wazuh : transformer des événements techniques bruts en alertes lisibles et en preuves de maturité.

Côté méthode, le durcissement gagne à être précédé d’un état des lieux. Pour savoir ce qui mérite d’être renforcé en premier, un diagnostic outillé fait gagner un temps précieux : d’un test d’intrusion e-commerce jusqu’à notre comparatif des outils d’audit de site, qui balaie performance, SEO et sécurité.

Les erreurs de durcissement les plus fréquentes

Certaines fausses bonnes idées reviennent constamment. Les connaître évite de perdre du temps sur des protections illusoires.

• Empiler les plugins de sécurité sans configurer le socle. Dix extensions mal réglées protègent moins qu’une configuration propre.
• Désactiver un module sans le supprimer. Un module désactivé reste présent sur le serveur, et son code peut encore être atteint.
• Oublier la préproduction. Les environnements de test, souvent moins protégés, sont une porte dérobée vers la production.
• Confondre « à jour » et « sécurisé ». Un site à jour côté cœur peut héberger un module obsolète, un compte fantôme ou un fichier sensible exposé.
• Négliger la dimension humaine. Un mot de passe partagé par messagerie ou un accès prestataire jamais révoqué annule une partie du travail technique.

Le durcissement entre aussi dans une logique de conformité de plus en plus exigeante. Les obligations qui se renforcent, notamment avec la directive NIS2 pour les PME, poussent à documenter ces mesures, pas seulement à les appliquer. Et les assureurs cyber regardent désormais ces preuves de très près.

Retour d’expérience : la boutique qu’on n’arrivait plus à décontaminer

Un cas réel, anonymisé.

À la fin de l’année 2025, un e-commerçant nous appelle, épuisé. Sa boutique PrestaShop, environ 800 K€ de CA, a été nettoyée deux fois en trois mois par deux prestataires différents. À chaque fois, mêmes symptômes : des redirections vers un site douteux qui apparaissent puis disparaissent, des fichiers modifiés sans explication, une alerte de Google Search Console pour contenu trompeur. Et à chaque fois, deux ou trois semaines après le nettoyage, tout recommence. Le dirigeant nous pose la seule question qui compte pour lui : « pourquoi ça revient toujours ? »

La réponse tient en une phrase : parce que personne n’avait fermé la porte. Nettoyer un site, c’est enlever les traces. Durcir un site, c’est empêcher qu’on les remette. Les deux prestataires précédents avaient fait le premier travail, jamais le second. Tant que l’entrée reste ouverte, l’attaquant, souvent un simple script automatisé, repasse par le même chemin et redépose sa charge. C’est exactement le scénario d’un site où plusieurs intrus reviennent tour à tour.

On a donc pris le problème à l’envers. Plutôt que de re-nettoyer une troisième fois en croisant les doigts, on a d’abord cherché comment ça rentrait. Trois portes, en réalité.

La première : un module de galerie photo, installé des années plus tôt pour une opération ponctuelle, jamais désinstallé, avec une faille d’upload de fichiers connue et publiquement documentée. C’est par là que le webshell revenait s’installer, tranquillement, à chaque fois. Le module était désactivé dans le back-office. Mais désactivé ne veut pas dire absent : son code était toujours sur le serveur, toujours atteignable directement par son URL. Le back-office disait « inactif », le serveur disait « exécutable ».

La deuxième : des permissions de fichiers beaucoup trop larges. Le serveur web pouvait écrire à peu près partout, y compris dans des dossiers qui n’avaient aucune raison d’être modifiables. Une fois le premier fichier malveillant déposé, il pouvait donc se propager sans obstacle. Un site correctement durci aurait cantonné l’intrus à une zone minuscule au lieu de lui ouvrir toute la maison.

La troisième, la plus rageante : un accès FTP d’un ancien freelance, avec un mot de passe faible, présent dans une fuite de données publique. L’attaquant n’avait même pas toujours besoin de la faille du module. Il se connectait, parfois, directement avec des identifiants valides. On ne casse pas une porte quand on a la clé.

Le durcissement a donc consisté, dans l’ordre : supprimer pour de bon le module fantôme et tous ses fichiers, resserrer les permissions selon le principe du moindre privilège, révoquer tous les accès dormants et régénérer les identifiants restants, forcer l’authentification à deux facteurs sur le back-office, et poser une surveillance d’intégrité des fichiers pour être prévenu à la seconde où un fichier apparaîtrait ou changerait. Le nettoyage final, celui qui a tenu, n’est venu qu’après. Dans le bon ordre, il n’a eu à se faire qu’une fois.

Ce qui a le plus marqué le dirigeant n’est pas technique. C’est de réaliser que ses deux prestataires précédents n’avaient pas été incompétents : ils avaient répondu exactement à la demande qu’on leur avait passée, « nettoyez le site ». Personne n’avait posé la vraie question, qui n’est pas « comment on enlève ça » mais « par où c’est entré ». Le nettoyage traite le symptôme. Le durcissement traite la cause. Facturer trois nettoyages successifs coûte plus cher, au final, qu’un durcissement fait une bonne fois.

Six mois plus tard, aucune récidive. Pas parce que le site est devenu impénétrable, ça n’existe pas, mais parce que les portes par lesquelles on entrait sont fermées, et que la surveillance signalerait immédiatement toute tentative d’en rouvrir une. La leçon que ce client retient aujourd’hui, et qu’il répète volontiers, tient en peu de mots : un site infecté qu’on nettoie sans le durcir n’est pas réparé, il est juste remis à disposition du prochain attaquant.

Faire durcir votre boutique sans devenir expert réseau

Sécuriser un CMS e-commerce ne demande pas de tout reconstruire. Ça demande de la méthode : réduire la surface d’attaque, fermer les portes inutiles, verrouiller les accès, maintenir dans le temps et surveiller. La plupart des compromissions que l’on voit sur le terrain n’exploitent pas une faille sophistiquée : elles passent par un module oublié, un compte mal protégé ou une configuration laissée par défaut. Autrement dit, par des points qu’un durcissement sérieux aurait fermés.

Chez Zetruc, on accompagne les e-commerçants sur ce sujet avec une double casquette web et cyber : l’équipe qui construit votre boutique est la même qui la protège. Audit de configuration, durcissement PrestaShop ou WordPress/WooCommerce, supervision continue, mise en conformité, formation des équipes : on adapte la profondeur à la taille de votre site, à votre budget et à votre niveau de maturité. Si vous n’êtes pas sûr de l’état de votre boutique, parlons-en avec notre équipe : on commence toujours par un point concret, sans jargon, pour identifier ce qui mérite d’être durci en priorité.