La supply chain des sites e-commerce : le danger des modules, plugins et dépendances tierces

Juin 2024, une petite bibliothèque JavaScript, utilisée gratuitement par plus de 100 000 sites dans le monde pour assurer la compatibilité avec les vieux navigateurs, change discrètement de propriétaire. Le nom de domaine qui l’héberge est racheté. Quelques semaines plus tard, le code servi par ce domaine se met à injecter des redirections malveillantes chez tous les sites qui le chargeaient. Les propriétaires de ces sites n’avaient rien installé, rien modifié, rien cliqué. Leur seule erreur : faire confiance, depuis des années, à une ligne de code qui pointait vers un serveur qui ne leur appartenait pas.

C’est ça, une attaque de supply chain. On ne force pas votre porte : on empoisonne un ingrédient que vous utilisez déjà. Et une boutique en ligne moderne, qu’elle tourne sous PrestaShop ou WordPress/WooCommerce, est un assemblage d’ingrédients que vous n’avez pas cuisinés vous-même : modules, plugins, thèmes, bibliothèques, scripts tiers, services externes. Chacun de ces maillons est une porte d’entrée potentielle. Voici comment cette chaîne est attaquée, pourquoi les boutiques en ligne sont des cibles de choix, et comment reprendre la main sans tout reconstruire.

La supply chain d’un site e-commerce, c’est quoi au juste ?

Le terme vient de la logistique : la chaîne d’approvisionnement, c’est tout ce qui se passe entre la matière première et le produit fini. Appliqué au logiciel, le principe est le même. Votre boutique n’est pas un bloc monolithique écrit par une seule équipe : c’est un empilement de composants venus d’ailleurs. Le cœur du CMS est développé par une communauté. Les modules et plugins par des éditeurs tiers. Le thème par un studio. Et chacun de ces composants embarque lui-même des dépendances : des bibliothèques de code réutilisées, qui en utilisent d’autres, qui en utilisent d’autres encore.

Un projet web professionnel s’appuie couramment sur plusieurs centaines de dépendances directes et indirectes. Personne ne relit tout ce code, et c’est normal : c’est justement le principe de la réutilisation. Le problème, c’est que la confiance accordée à chaque brique est implicite. On ne questionne pas une bibliothèque qu’on utilise depuis des années. Les attaquants l’ont parfaitement compris : plutôt que d’attaquer 10 000 boutiques une par une, il est beaucoup plus rentable de compromettre un seul module installé sur ces 10 000 boutiques.

Sur un site marchand, l’enjeu est encore plus lourd qu’ailleurs. La chaîne aboutit à un endroit précis : la page de paiement, là où transitent les numéros de carte. C’est la cible favorite des attaques par web skimming, ces scripts discrets qui copient les données saisies au checkout sans jamais perturber le fonctionnement de la boutique.

Cartographier les maillons de votre chaîne

Avant de sécuriser quoi que ce soit, il faut savoir de quoi votre boutique dépend. La plupart des dirigeants sous-estiment largement la longueur de leur chaîne. Elle comprend au minimum :

• Le cœur du CMS : PrestaShop ou WordPress, avec son propre rythme de versions et de correctifs de sécurité.
• Les modules et plugins : paiement, livraison, avis clients, SEO, cache, statistiques. C’est le maillon le plus fourni et le plus fragile.
• Le thème : du code à part entière, souvent bourré de bibliothèques embarquées, rarement mis à jour après l’achat.
• Les scripts tiers chargés côté navigateur : mesure d’audience, chat, avis, reciblage publicitaire, polices web. Ils s’exécutent chez vos visiteurs, y compris sur la page de paiement.
• Les briques de développement : bibliothèques installées par votre prestataire lors de la construction du site, invisibles dans le back-office mais bien présentes sur le serveur.
• Les services externes connectés : passerelles de paiement, transporteurs, places de marché, outils d’emailing, chacun relié par une API et des identifiants.

Chaque ligne de cette liste est un fournisseur. Et comme dans une chaîne logistique classique, votre sécurité réelle est celle du maillon le plus faible, pas celle du maillon le plus solide.

Les cinq visages d’une attaque supply chain

Toutes les attaques par la chaîne ne se ressemblent pas. En voici les grandes familles, avec ce qu’elles donnent concrètement sur une boutique.

Le point commun de ces cinq scénarios : dans aucun d’eux vous n’avez commis d’imprudence visible. Pas de pièce jointe ouverte, pas de mot de passe donné au téléphone. L’attaque arrive par un canal que vous considériez comme légitime. C’est ce qui rend le sujet à la fois déstabilisant et prioritaire.

Modules PrestaShop : le maillon historique

Sur PrestaShop, les statistiques de vulnérabilités publiées année après année racontent la même histoire : l’écrasante majorité des failles ne concerne pas le cœur du CMS, mais les modules tiers. Injection SQL dans un module de filtre, upload de fichier arbitraire dans un module de galerie, fuite de données dans un module de statistiques : le schéma se répète, et des campagnes automatisées scannent en continu le web à la recherche de boutiques équipées des versions vulnérables.

Nous avons décortiqué ce mécanisme pas à pas dans notre anatomie d’une cyberattaque sur un site e-commerce : de la faille publiée au skimmer en place, il se passe parfois moins de 48 heures. Trois questions à poser avant chaque installation de module, et à reposer une fois par an pour ceux qui sont déjà en place : qui maintient ce module, à quand remonte sa dernière mise à jour, et est-il toujours nécessaire au fonctionnement de la boutique. Un module désactivé mais toujours présent sur le serveur reste attaquable : son code est là, atteignable, exécutable.

Plugins et thèmes WordPress : l’écosystème le plus scanné du monde

WordPress propulse plus de 40 % du web, et WooCommerce en fait la première plateforme e-commerce mondiale en nombre de sites. Cette popularité a un revers : l’écosystème de plugins est le plus surveillé qui soit, par les chercheurs en sécurité comme par les attaquants. Chaque semaine, des dizaines de vulnérabilités de plugins sont publiées, et chaque publication déclenche une course entre les boutiques qui mettent à jour et les robots qui exploitent.

La logique supply chain y prend une dimension supplémentaire : le rachat de plugins. Un plugin populaire mais peu rentable est racheté par un acteur opaque, qui pousse ensuite une mise à jour contenant une porte dérobée. Le canal de distribution officiel devient le vecteur de l’attaque. Même mécanique côté thèmes : un thème premium acheté sur une place de marché embarque des dizaines de bibliothèques figées à la date de sa création, qui vieillissent silencieusement pendant que le thème, lui, affiche fièrement sa dernière version.

Sur WooCommerce, la vigilance se concentre en priorité sur les extensions qui touchent à l’argent et aux données personnelles : paiement, facturation, export de commandes, comptes clients. Ce sont elles qui intéressent les attaquants, et ce sont donc elles qui méritent l’audit le plus sérieux avant installation.

PrestaShop ou WordPress : mêmes risques, chaînes différentes

Les deux plateformes convergent vers la même règle : chaque composant tiers installé est un fournisseur à qui vous confiez les clés de votre boutique. On ne choisit pas un fournisseur uniquement sur sa fiche produit.

Les dépendances invisibles : scripts front, CDN et briques de développement

La partie la plus négligée de la chaîne est celle qu’on ne voit pas dans le back-office. D’abord les scripts tiers chargés dans le navigateur de vos visiteurs : chat, avis, mesure d’audience, reciblage. Chacun de ces scripts s’exécute avec les pleins pouvoirs sur vos pages, y compris au checkout. Si le serveur qui le distribue est compromis, ou si le domaine est racheté comme dans l’affaire de 2024 évoquée en introduction, l’injection touche instantanément tous les sites clients. La question à se poser pour chaque script : a-t-il vraiment besoin d’être présent sur la page de paiement ?

Ensuite, les briques installées lors du développement du site : bibliothèques et paquets récupérés sur des registres publics. Les attaques y sont devenues courantes : paquets imitant le nom d’une bibliothèque légitime à une lettre près, comptes de mainteneurs compromis, code malveillant qui s’exécute dès l’installation. C’est le terrain de votre prestataire, mais c’est votre boutique qui en subit les conséquences. Vous êtes en droit de lui demander comment il verrouille les versions de ses dépendances et comment il vérifie ce qu’il installe.

Réduire le risque : cinq réflexes qui changent tout

Il n’existe pas de bouton magique, mais une méthode. Cinq réflexes couvrent l’essentiel du risque supply chain d’une boutique :

• Inventorier. Lister tous les modules, plugins, thèmes et scripts tiers actifs, avec leur éditeur et leur date de dernière mise à jour. On ne protège pas ce qu’on ignore posséder.
• Réduire. Désinstaller complètement tout ce qui ne sert plus. Chaque composant retiré est une porte murée. C’est le cœur de la démarche de durcissement de PrestaShop et WordPress/WooCommerce que nous détaillons par ailleurs.
• Auditer avant d’installer. Éditeur identifiable, mises à jour récentes, permissions demandées cohérentes avec la fonction. Trois vérifications, deux minutes, des mois de tranquillité.
• Mettre à jour vite, mais avec un filet. Appliquer les correctifs de sécurité rapidement, sur un environnement de préproduction d’abord quand c’est possible, avec une sauvegarde testée avant toute mise à jour majeure.
• Surveiller l’intégrité. Un fichier qui apparaît ou change sans action de votre part est le signal d’alerte numéro un. C’est exactement ce que permet la surveillance d’un site web avec Wazuh : détecter en minutes ce qui, sinon, serait découvert en mois.

Les erreurs les plus fréquentes face au risque supply chain

Certains réflexes, bien intentionnés, passent complètement à côté du sujet.

• Croire qu’un module payant est forcément sûr. Le prix rémunère des fonctionnalités, pas un audit de sécurité. Des modules commerciaux très diffusés ont porté des failles majeures.
• Confondre désactivé et supprimé. Un composant désactivé reste présent sur le serveur, et son code reste souvent atteignable directement.
• Faire confiance aveuglément aux mises à jour. La mise à jour reste indispensable, mais elle mérite un environnement de test et une sauvegarde préalable, précisément parce que le canal de mise à jour peut lui-même être attaqué.
• Oublier le front-end. Auditer ses plugins serveur en laissant douze scripts tiers non maîtrisés sur la page de paiement, c’est verrouiller la cave en laissant la vitrine ouverte.
• Penser que c’est le problème du prestataire. Juridiquement et commercialement, c’est votre boutique, vos clients, vos données. La directive NIS2 pour les PME pousse d’ailleurs explicitement les entreprises à évaluer la sécurité de leur chaîne de sous-traitance et à documenter ces vérifications.

Retour d’expérience : la boutique trahie par ses propres fournisseurs

Un cas de terrain, anonymisé et reconstitué à partir de plusieurs situations observées.

Début 2026, le responsable d’une boutique en ligne d’équipement professionnel nous contacte. Le tableau est classique en apparence : une alerte de contenu trompeur dans la Search Console, un skimmer découvert sur la page de paiement, un nettoyage effectué en urgence par l’hébergeur. Deux semaines plus tard, le skimmer est de retour, au même endroit, avec une signature légèrement différente. Le dirigeant n’a rien installé, rien modifié entre-temps. Sa question tient en une phrase : « comment un site qu’on vient de nettoyer peut-il se réinfecter tout seul ? »

Réponse : il ne se réinfecte pas tout seul. Il se réinfecte par sa chaîne. Plutôt que de re-nettoyer une deuxième fois, on a inventorié tous les composants tiers de la boutique : 41 modules et plugins, un thème premium, et 9 scripts externes chargés côté navigateur. Sur ces 51 fournisseurs de code, trois posaient un problème sérieux.

Le premier : un module de galerie photo, installé des années plus tôt par un ancien prestataire pour une opération ponctuelle, jamais désinstallé. Son éditeur avait cessé toute activité, et une faille d’upload de fichiers le concernant était publiquement documentée. C’était la porte d’entrée principale : les scanners automatiques des attaquants la retrouvaient à chaque passage. Le module était désactivé dans le back-office, mais son code restait présent sur le serveur, atteignable directement par son URL.

Le deuxième : un script d’avis clients chargé sur toutes les pages, y compris au checkout, depuis un domaine dont le service d’origine avait fermé. Le domaine, lui, répondait toujours. Personne ne savait qui le contrôlait désormais. Autrement dit : un inconnu disposait d’un droit d’exécution de code chez chaque visiteur de la boutique, au moment précis où il tapait son numéro de carte.

Le troisième : le thème, acheté sur une place de marché en 2021 et jamais mis à jour depuis, embarquait une version d’une bibliothèque JavaScript porteuse de failles corrigées depuis longtemps ailleurs. Le cœur du CMS était à jour, les plugins principaux aussi : le back-office affichait un site « sain ». La chaîne, elle, disait le contraire.

Le traitement a suivi l’ordre logique : suppression complète du module fantôme et de tous ses fichiers, retrait du script orphelin et revue de chaque script tiers encore chargé au checkout, remplacement du thème vieillissant par une version maintenue, puis pose d’une surveillance d’intégrité des fichiers pour être alerté à la seconde où un fichier apparaîtrait ou changerait. Le nettoyage final n’est venu qu’après. Fait dans le bon ordre, il n’a eu à se faire qu’une fois. L’investigation a aussi confirmé un phénomène que nous avons déjà décrit : quand une porte reste ouverte assez longtemps, un site piraté héberge souvent plusieurs intrus. Deux charges distinctes cohabitaient sur cette boutique, déposées par des groupes différents via la même faille.

Ce qui a le plus marqué le dirigeant n’est pas technique. C’est de réaliser que sa boutique dépendait de 51 fournisseurs de code dont il ignorait l’existence pour la plupart, et qu’aucun contrat, aucun tableau de bord, aucun réflexe de gestion ne couvrait ces fournisseurs-là. Six mois plus tard, aucune récidive. Pas parce que le site est devenu invulnérable, mais parce que sa chaîne est désormais connue, réduite au nécessaire, et surveillée. La leçon qu’il retient tient en peu de mots : on ne peut pas défendre une chaîne dont on n’a jamais fait l’inventaire.

Reprendre la main sur votre chaîne logicielle, sans tout reconstruire

Sécuriser sa supply chain ne demande pas de renoncer aux modules et plugins : ils sont la force de PrestaShop et de WordPress. Ça demande de les traiter pour ce qu’ils sont, des fournisseurs, avec ce que ça implique : un inventaire, des critères de sélection, un suivi dans le temps et une capacité à détecter quand l’un d’eux trahit la confiance accordée. La quasi-totalité des compromissions de boutiques que l’on rencontre passe par un composant tiers connu, vieilli ou oublié. Autrement dit, par un maillon qu’un examen sérieux de la chaîne aurait repéré.

Chez Zetruc, on aborde ce sujet avec une double casquette web et cyber : l’équipe qui construit et maintient votre boutique est la même qui surveille sa chaîne logicielle. Inventaire des dépendances, audit des modules et plugins, durcissement, supervision continue, mise en conformité : on adapte la profondeur à la taille de votre site et à votre budget. Si vous ne savez pas aujourd’hui combien de composants tiers tournent sur votre boutique ni qui les maintient, c’est précisément le bon moment : parlons-en avec notre équipe, on commence toujours par un état des lieux concret, sans jargon, pour identifier les maillons à traiter en priorité.