Le coût de la sécurité d’une boutique PrestaShop se paie au moment où l’on achète un module, pas au moment de l’incident. Sur une boutique en production, la question n’est presque jamais « faut-il mettre à jour » — tout le monde répond oui — mais « qu’est-ce qui empêche de mettre à jour ». Et la réponse, sur la grande majorité des boutiques que nous auditons, tient en un mot : un module. Un module acheté vite, jamais testé en préproduction, dont l’éditeur a cessé les mises à jour, et qui cloue la boutique sur une version du cœur que plus personne ne corrige.
Cet article démontre cette affirmation par l’arithmétique plutôt que par l’anecdote. On y pose la formule qui relie le nombre de modules installés à la probabilité qu’une montée de version soit bloquée, on la calcule pour des valeurs que chacun peut refaire à la main, on décrit un calendrier de mise à jour qui tient dans la durée, et on compare le coût des deux approches — proactive et corrective — en séparant explicitement ce qui se mesure de ce qui reste une hypothèse.
Ce qu’un attaquant cherche sur une boutique
La page d’accueil défigurée est l’image d’Épinal de l’attaque. C’est aussi le scénario le moins probable, parce que c’est le moins rentable. Une boutique en ligne concentre trois choses qui se monnayent : des données de commande (identités, adresses, historiques d’achat, parfois des débuts de numéros de carte selon le prestataire de paiement), une capacité d’envoi de courriels avec une réputation d’expéditeur propre, et du trafic qualifié qu’on peut détourner.
Les attaques qui rapportent sont donc silencieuses. L’injection d’un script de captation dans le tunnel de commande — le formulaire de paiement est recopié vers un serveur tiers pendant que la commande aboutit normalement — peut rester invisible des mois : ni le client ni le marchand ne voient d’anomalie, seule la banque finit par remonter des fraudes en série. Le détournement discret du référencement (pages de spam injectées, redirections servies aux seuls robots) exploite l’autorité du domaine sans toucher à ce que voit le marchand connecté. L’exfiltration de la table des clients se revend, tout simplement.
Cette hiérarchie change la manière de surveiller. Vérifier que « le site marche » ne protège de rien : dans les trois scénarios ci-dessus, le site marche parfaitement. Ce qu’il faut surveiller, c’est ce qui a changé dans les fichiers, ce qui part vers des domaines tiers depuis les pages de paiement, et ce que les robots voient de votre site — trois choses qu’on ne constate jamais en navigant soi-même.
Les points d’entrée réels, classés
Le recensement des dix vulnérabilités les plus fréquentes que nous avons publié pour les sites français vaut aussi pour les boutiques, mais l’ordre y change : sur PrestaShop, les avis de sécurité publiés par l’équipe du projet et par les chercheurs qui suivent l’écosystème concernent massivement des modules, pas le cœur. La raison est structurelle : le cœur est relu par beaucoup de monde, un module l’est par son seul éditeur, et un module abandonné n’est plus relu par personne.
| Point d’entrée | Ce qui le rend possible | Vérification à lancer |
|---|---|---|
| Module vulnérable ou abandonné | Achat sans lecture du code, éditeur disparu, version figée | Inventaire par la requête sur ps_module donnée plus bas, croisé avec les avis de sécurité de chaque éditeur |
| Cœur non mis à jour | Un module bloque la montée de version (voir la section suivante) | Comparer la constante _PS_VERSION_ à la dernière version publiée par le projet |
| Interface d’administration exposée | Répertoire d’admin au nom prévisible, absence de restriction d’accès | Tester l’URL depuis une connexion extérieure ; restreindre par adresse IP ou authentification supplémentaire au niveau du serveur |
| Comptes employés dormants | Départs non suivis d’une désactivation | SELECT email, active FROM ps_employee; puis désactiver ce qui ne correspond plus à un humain en poste |
| Accès FTP/SSH partagés | Le même mot de passe circule entre prestataires successifs | Lister les comptes chez l’hébergeur, révoquer, passer aux clés |
| Formulaires d’envoi de fichiers | Module de personnalisation ou de SAV qui accepte tout type de fichier | Envoyer un fichier .php renommé et vérifier qu’il est refusé côté serveur, pas seulement côté navigateur |
Deux remarques sur ce tableau. D’abord, quatre lignes sur six ne demandent aucune compétence de développement : ce sont des vérifications d’inventaire et de droits d’accès, à la portée de quiconque administre la boutique. Ensuite, aucune ligne ne se vérifie « une fois pour toutes » : un inventaire de modules est périmé au premier achat suivant, une liste de comptes au premier départ. C’est pour cela que la section sur la surveillance parle de fréquences, pas d’actions.
Pourquoi une boutique reste sur une version ancienne : l’arithmétique des modules
Voici le raisonnement central de cet article. Chaque module installé a une certaine probabilité p de bloquer une montée de version donnée : incompatibilité déclarée, dépendance à un comportement retiré du cœur, éditeur qui n’a pas suivi, surcharge de classe qui entre en conflit. Cette probabilité varie selon la qualité du module et l’ampleur de la montée de version, mais pour une boutique donnée elle s’estime : il suffit de rejouer la dernière montée de version en préproduction et de compter combien de modules ont posé problème.
Si les blocages sont supposés indépendants d’un module à l’autre — hypothèse simplificatrice, assumée comme telle, qui tend plutôt à sous-estimer le risque puisque les modules d’un même éditeur tombent souvent ensemble —, la probabilité qu’au moins un module sur n bloque la montée s’écrit :
P(au moins un blocage) = 1 - (1 - p)^nCette formule se vérifie avec n’importe quelle calculatrice. Voici ce qu’elle donne pour trois valeurs de p et quatre tailles de parc de modules :
| Modules tiers installés | p = 5 % | p = 10 % | p = 20 % |
|---|---|---|---|
| 10 modules | 40 % | 65 % | 89 % |
| 20 modules | 64 % | 88 % | 99 % |
| 30 modules | 79 % | 96 % | 99,9 % |
| 40 modules | 87 % | 99 % | presque 100 % |
Lisez la première colonne : même en supposant des modules de bonne facture — un sur vingt seulement pose problème à chaque montée de version —, une boutique de trente modules a environ quatre chances sur cinq de voir sa prochaine montée bloquée par au moins l’un d’eux. C’est pour cela que « la boutique n’est pas à jour » n’est presque jamais une négligence : c’est la conséquence mécanique d’un parc de modules constitué sans règle. Le mot juste n’est pas paresse, c’est arithmétique.
La conséquence pratique est double. En amont, chaque module ajouté doit être traité comme un engagement de long terme, pas comme un achat de confort — c’est l’objet d’un article entier de cette série. En aval, réduire n avant une montée de version majeure est souvent le vrai travail : sur un chantier de migration vers PrestaShop 9, l’inventaire et la désinstallation des modules morts précèdent toute autre tâche, parce que chaque module retiré fait chuter la probabilité de blocage de toute la suite du chantier.
Une précision d’honnêteté sur ce modèle : p ne se mesure pas sur un banc. Il dépend des éditeurs de vos modules, de leur réactivité et de l’écart entre les deux versions concernées. Ce qui se mesure, c’est votre p, et il s’obtient en tenant un relevé : à chaque montée de version sur préproduction, notez combien de modules ont dû être remplacés, mis à jour contre paiement ou abandonnés. Trois montées de version suffisent à donner un ordre de grandeur utilisable pour la quatrième, et ce relevé vaut mieux que n’importe quelle moyenne publiée, parce qu’il porte sur votre parc et sur vos éditeurs.
Le calendrier de mise à jour qui tient
Un calendrier de mise à jour échoue pour une raison simple : il est conçu pour un monde où tout se passe bien. Le calendrier qui tient est celui qui prévoit l’échec — c’est-à-dire qui réserve, à chaque fenêtre, le temps de constater qu’un module casse et de revenir en arrière proprement.
La routine que nous appliquons tient en quatre temps, et chacun a une raison d’exister. Une fenêtre mensuelle fixe, posée dans l’agenda comme un rendez-vous client, parce qu’une tâche sans créneau est une tâche qui n’existe pas. Une préproduction qui est une copie de la production — mêmes versions, mêmes modules, base récente anonymisée — parce que tester une mise à jour sur autre chose que la réalité revient à ne pas la tester. Un rejeu de commande après chaque mise à jour : une commande de bout en bout, avec un paiement en mode test, un compte client, un code promotionnel si la boutique en use — parce que c’est le tunnel de commande qui paie tout le reste, et que c’est lui que les régressions touchent en premier. Enfin une procédure de retour arrière écrite — fichiers et base, dans cet ordre, avec l’emplacement exact des sauvegardes — parce qu’un retour arrière improvisé à 23 h est le moment où l’on aggrave un incident au lieu de le clore.
Sur les durées, l’honnêteté oblige à dire qu’elles dépendent entièrement de la boutique : une fenêtre nous prend couramment une à trois heures selon le nombre de correctifs accumulés, mais la seule valeur qui compte est la vôtre — chronométrez deux fenêtres, et vous connaîtrez votre coût annuel par une simple multiplication. À 2 h par fenêtre mensuelle, l’entretien du cœur et des modules coûte 24 h par an ; c’est ce chiffre-là, le vôtre, qu’il faudra poser en face du scénario correctif dans le tableau de fin d’article.
Un mot sur les versions majeures : elles ne rentrent pas dans la fenêtre mensuelle. Une montée de version majeure est un projet, avec son inventaire de modules, ses arbitrages de remplacement et son propre rejeu complet — le sujet dépasse cet article et nous l’avons traité séparément.
Ce qui doit être surveillé, et à quelle fréquence
La surveillance utile est celle qui détecte un changement, pas celle qui constate un état. Voici la liste minimale, avec pour chaque élément la fréquence et le moyen — de préférence une commande, parce qu’une commande se relance à l’identique et se met dans une tâche planifiée.
| Élément surveillé | Fréquence | Moyen |
|---|---|---|
| Fichiers modifiés sur le serveur | Quotidienne | find . -type f -mtime -2 -not -path "./var/*" — toute modification hors déploiement connu est un incident jusqu’à preuve du contraire ; si le code est suivi en versionnage, git status fait mieux |
| Avis de sécurité du cœur et des modules installés | Mensuelle, dans la fenêtre | Flux d’annonces du projet et pages de chaque éditeur — l’inventaire de modules sert de liste de contrôle |
| Comptes employés et leurs droits | Mensuelle, et à chaque départ | SELECT email, active FROM ps_employee; croisé avec la liste réelle des personnes en poste |
| Certificat et sa date d’expiration | Automatique, alerte à 15 jours | echo | openssl s_client -connect boutique.example:443 2>/dev/null | openssl x509 -noout -enddate |
| Requêtes sortantes des pages de paiement | À chaque mise à jour, et trimestrielle | Onglet réseau du navigateur sur la page de paiement : chaque domaine tiers doit être connu et justifiable |
| Ce que voient les robots | Hebdomadaire | Rapport de couverture de la console de recherche : une explosion de pages indexées inconnues signale une injection de contenu |
Cette table remplit une page d’agenda, pas un poste à temps plein. C’est le point important : la surveillance d’une boutique de taille moyenne est un ensemble de rituels courts, pas une compétence rare. Ce qui demande une compétence rare, c’est l’investigation après incident — précisément ce que la surveillance sert à éviter.
La sauvegarde : une sauvegarde jamais restaurée est une hypothèse
Toutes les boutiques ont des sauvegardes. Une partie d’entre elles ont des sauvegardes restaurables, et personne ne sait dans quelle partie il se trouve avant d’avoir essayé. Une archive peut être tronquée, chiffrée avec une clé perdue, produite pendant une écriture et donc incohérente, ou tout simplement vide depuis qu’un chemin a changé. Tant qu’une restauration complète n’a pas été menée jusqu’à une boutique fonctionnelle, la sauvegarde est une hypothèse, pas une protection.
Le test de restauration se fait sans risque sur une base jetable :
mysqldump --single-transaction --routines nom_base | gzip > sauvegarde.sql.gz
mysql -e "CREATE DATABASE restauration_test"
gunzip -c sauvegarde.sql.gz | mysql restauration_testLa vérification ne s’arrête pas au succès de la commande : comparez les comptages des tables sensibles entre l’original et la restauration — SELECT COUNT(*) FROM ps_orders;, même chose sur ps_customer et ps_order_detail — puis montez la copie de fichiers en préproduction et passez une commande de test. Le chronomètre, pendant ce temps, mesure la seule donnée qui intéresse la direction : combien de temps la boutique resterait fermée en cas de restauration réelle.
Reste la question que la direction pose et à laquelle personne ne répond avec un chiffre : combien de temps une restauration prend-elle ? Un banc a été monté pour cette série, sur une base de boutique réaliste — commandes, lignes de commande et clients, avec l’index sur les lignes. Le moteur est SQLite et le disque est local et rapide : les rapports sont transposables, les valeurs absolues seront plus élevées sur un hébergement mutualisé.
| Commandes | Lignes | Base | Fichier d’export | Export | Restauration |
|---|---|---|---|---|---|
| 10 000 | 30 000 | 1,7 Mo | 2,6 Mo | 0,08 s | 0,14 s |
| 100 000 | 300 000 | 17,6 Mo | 26,7 Mo | 0,81 s | 1,42 s |
| 500 000 | 1 500 000 | 89,8 Mo | 136,8 Mo | 4,15 s | 6,88 s |
Trois rapports à retenir, et ils sont stables sur les trois volumes. La restauration coûte environ 1,7 fois l’export : rejouer des insertions est plus lent que les écrire. Le fichier d’export pèse environ une fois et demie la base, ce qui compte pour le dimensionnement de l’espace d’archivage et pour le transfert. Et la reconstruction des index représente 13 pour cent de la restauration — c’est-à-dire qu’une restauration qui semble finie mais dont les index sont en cours de reconstruction laisse une boutique fonctionnelle et lente.
Le chiffre qui manque à ce tableau est celui qui domine en situation réelle : le transfert. Un fichier d’export de 136,8 mégaoctets qu’il faut télécharger depuis l’archivage puis renvoyer vers le serveur représente 2 min 17 dans chaque sens sur un lien à huit mégabits par seconde, et 9 min 7 sur un lien à deux mégabits. Les sept secondes de rejeu sont anecdotiques devant ces vingt minutes. C’est la raison pour laquelle l’archivage doit être proche du serveur de production — et la raison pour laquelle « on a des sauvegardes » n’est pas une réponse : la question est « combien de temps la boutique reste-t-elle fermée ».
Deux règles complètent le test. La sauvegarde doit vivre ailleurs que la boutique — un attaquant qui obtient le serveur obtient aussi les archives qui y dorment, et les rançongiciels chiffrent d’abord les sauvegardes accessibles. Et la fréquence se déduit d’une question simple : combien d’heures de commandes acceptez-vous de perdre ? La réponse, en heures, est votre intervalle de sauvegarde de la base ; pour les fichiers, une sauvegarde par déploiement suffit puisqu’ils ne changent qu’au déploiement.
Les obligations en cas de fuite de données
Une boutique traite des données personnelles ; une intrusion qui les expose déclenche donc des obligations légales, avec un délai qui se compte en heures. La règle centrale mérite d’être posée précisément :
En cas de violation de données à caractère personnel, le responsable du traitement la notifie à l’autorité de contrôle dans les meilleurs délais et, si possible, au plus tard 72 heures après en avoir pris connaissance, sauf si la violation n’est pas susceptible d’engendrer un risque pour les droits et libertés des personnes ; passé ce délai, la notification s’accompagne des motifs du retard.
— résumé de l’article 33, règlement général sur la protection des données
Le même texte prévoit, à l’article suivant, l’information directe des personnes concernées lorsque le risque est élevé — ce qui est le cas typique d’une captation de données de paiement — et la tenue d’une documentation interne de toute violation, notifiée ou non. Ce dernier point est le plus souvent ignoré : même une intrusion jugée sans risque doit laisser une trace écrite, datée, avec les faits, les effets et les mesures prises.
Ces 72 heures changent la nature du sujet. Elles supposent de savoir quand l’intrusion a commencé, quelles tables ont été lues, quels clients sont concernés — trois questions auxquelles seuls des journaux conservés et une intégrité de fichiers suivie permettent de répondre. Autrement dit, la capacité à remplir l’obligation légale se construit avant l’incident ; après, il est trop tard pour avoir des journaux. Les sanctions prévues par le règlement existent et sont publiées par l’autorité de contrôle ; nous ne citerons pas de montant type, car chaque décision dépend des circonstances — consultez les décisions publiées, elles sont publiques et instructives.
Proactif ou correctif : le tableau
Il reste à poser les deux approches côte à côte. Les montants absolus dépendent de chaque boutique, donc le tableau donne des formules et un exemple calculé, pas des chiffres à recopier : remplacez les paramètres par les vôtres, la structure de la comparaison, elle, ne bouge pas.
| Poste | Approche proactive | Approche corrective |
|---|---|---|
| Entretien courant | 12 fenêtres × durée de fenêtre ; à 2 h : 24 h/an, planifiées, au tarif normal | 0 h — c’est tout l’attrait apparent |
| Test de restauration | 4 tests × durée mesurée ; à 1 h : 4 h/an | La première restauration réelle sert de test, pendant l’incident |
| Indisponibilité | Fenêtres hors pointe, interruption évitable ou de quelques minutes | Jours d’arrêt × marge quotidienne de la boutique — paramètre que vous connaissez mieux que quiconque |
| Investigation | Sans objet | Facturée au temps passé, en urgence, par un profil rare — le devis ne se négocie pas un serveur à terre |
| Obligations légales | Journaux et documentation déjà en place | Notification sous 72 h avec des journaux peut-être absents ; information individuelle des clients touchés |
| Prévisibilité | Totale : le coût est un budget | Nulle : le coût est une distribution dont vous tirez un échantillon |
La dernière ligne est la vraie conclusion. L’approche proactive transforme un risque en budget : quelques dizaines d’heures par an, connues d’avance, lissées — c’est exactement ce qu’un contrat de maintenance de site internet met sous forfait. L’approche corrective ne coûte rien la plupart des années, puis coûte un montant inconnu, borné vers le bas par plusieurs jours de marge et vers le haut par rien du tout, l’année où la ligne « module vulnérable » du premier tableau se réalise. Choisir entre les deux n’est pas une question technique, c’est une préférence pour le risque — et elle appartient au dirigeant, à condition qu’elle soit prise en connaissance des deux colonnes.
Un dernier arbitrage assumé : si le budget ne permet qu’une seule chose, faites l’inventaire des modules et le test de restauration avant tout le reste. Le premier réduit la probabilité de l’incident, le second borne sa gravité ; tout prestataire sérieux de développement PrestaShop commencera par ces deux-là.
Ce qu’il faut retenir
La sécurité d’une boutique ne se décide pas dans les réglages : elle se décide dans le parc de modules. La formule 1 − (1 − p)^n dit pourquoi les boutiques prennent du retard : à trente modules et une probabilité unitaire de blocage de 5 % seulement, la probabilité qu’une montée de version soit bloquée atteint 79 % ; à 10 %, elle atteint 96 %. Chaque module retiré fait mécaniquement baisser ce chiffre, chaque module ajouté l’augmente — c’est un engagement, pas un achat.
Le calendrier qui tient est court et régulier : une fenêtre mensuelle avec préproduction et rejeu de commande, un test de restauration trimestriel chronométré, une liste de surveillance qui tient en six lignes. À 2 h par fenêtre, l’entretien annuel se compte en dizaines d’heures — un budget, pas un pari. Et une sauvegarde jamais restaurée reste une hypothèse : le seul test qui vaille se termine par une boutique fonctionnelle et un temps de restauration mesuré.
Enfin, une fuite de données déclenche une notification à l’autorité de contrôle sous 72 heures, et cette obligation ne se remplit qu’avec des journaux constitués avant l’incident. C’est le résumé de tout l’article : dans l’approche proactive, chaque euro achète de la prévisibilité ; dans l’approche corrective, chaque euro économisé achète un ticket pour une loterie dont vous ne connaissez ni la date du tirage ni le montant du lot.
