Le scénario mérite l’attention de tous les e-commerçants, même ceux qui n’ont jamais ouvert un back-office BigCommerce.
La plateforme n’a pas été piratée.
Les boutiques pouvaient être correctement maintenues.
Et pourtant, des attaquants ont réussi à accéder à des données clients et à injecter des scripts malveillants dans certaines boutiques.
Le point d’entrée ?
Les identifiants d’une application tierce disposant déjà d’un accès légitime à BigCommerce.
BigCommerce a confirmé le 17 septembre que des identifiants API appartenant aux applications Ribon et Ribon 1.5, éditées par Be A Part Of, une société de Fastr, avaient été compromis à la suite d’une compromission d’un système de Fastr. Ces accès ont ensuite été utilisés contre des boutiques utilisant l’application.
Une attaque qui rappelle une règle assez simple : la sécurité d’une boutique ne s’arrête pas à celle de son CMS.
Sommaire
- Que s’est-il passé chez BigCommerce ?
- Comment une application tierce a-t-elle ouvert l’accès aux boutiques ?
- Quelles données clients ont été exposées ?
- BigCommerce a-t-il été piraté ?
- Pourquoi les clés API sont-elles si sensibles ?
- Shopify, WooCommerce et PrestaShop sont-ils concernés par le même risque ?
- Comment auditer les applications connectées à une boutique ?
- Le nouveau périmètre de la sécurité e-commerce
- Que retenir de cet article ?
Que s’est-il passé chez BigCommerce ?
L’incident concerne les applications Ribon et Ribon 1.5, utilisées pour optimiser l’expérience d’achat sur des boutiques BigCommerce.
Selon les informations communiquées par BigCommerce, des identifiants API associés à ces applications ont été compromis à la suite d’une compromission chez Fastr.
L’activité malveillante documentée s’étend du 13 au 17 septembre 2026.
BigCommerce indique avoir confirmé l’incident le 17 septembre.
La plateforme a ensuite désinstallé les applications concernées des boutiques affectées afin de révoquer l’accès des attaquants, prévenu les marchands et fourni des logs pour aider à l’enquête.
Les identifiants compromis ont notamment été utilisés pour injecter des scripts malveillants dans un petit nombre de storefronts, selon BigCommerce.
Mais l’incident ne s’arrête pas à l’injection de JavaScript.
Comment une application tierce a-t-elle ouvert l’accès aux boutiques ?
Une application e-commerce a souvent besoin de communiquer avec le CMS.
Afficher des recommandations produit, synchroniser un catalogue, automatiser du marketing ou personnaliser une expérience nécessite l’accès à certaines données ou fonctions de la boutique.
Cet accès passe fréquemment par une API.
Une clé ou un token permet alors à l’application de s’authentifier auprès de la plateforme.
Le principe est parfaitement normal.
Le problème commence lorsque cet identifiant tombe entre de mauvaises mains.
Dans le cas Ribon, l’attaquant n’avait pas besoin de trouver une nouvelle faille dans BigCommerce.
Il disposait d’un accès qui, du point de vue de la plateforme, provenait d’une application autorisée.
Le marchand britannique Master of Malt, touché par l’incident, explique que les attaquants ont utilisé la clé compromise pour parcourir et télécharger des données clients jusqu’à sa révocation.
La frontière entre utilisation légitime d’une API et attaque devient alors beaucoup plus difficile à distinguer.
Quelles données clients ont été exposées ?
Master of Malt a confirmé l’accès à plusieurs catégories de données :
- noms complets ;
- adresses email ;
- numéros de téléphone ;
- adresses postales de livraison.
En revanche, BigCommerce indique que les mots de passe et les informations de cartes bancaires sont stockés séparément et n’ont pas été exposés par cet incident.
C’est évidemment une distinction importante.
Mais nom + email + téléphone + adresse constituent déjà un ensemble de données particulièrement intéressant pour des campagnes de phishing ou d’ingénierie sociale.
Master of Malt a d’ailleurs averti ses clients qu’il ne leur demanderait jamais de transmettre mots de passe ou données de paiement par téléphone ou email à la suite de l’incident.
Le risque ne s’arrête donc pas nécessairement au moment où la clé compromise est révoquée.
BigCommerce a-t-il été piraté ?
Non, d’après les informations disponibles.
Et la nuance est importante.
BigCommerce affirme explicitement que l’incident n’est pas une compromission de ses systèmes ou de sa plateforme.
Les identifiants compromis appartenaient aux applications tierces Ribon et Ribon 1.5.
On se trouve donc davantage face à une attaque de supply chain : l’attaquant compromet un élément connecté à l’écosystème pour atteindre ensuite les organisations qui lui ont accordé leur confiance.
C’est précisément ce qui rend ce type d’incident intéressant au-delà du cas BigCommerce.
La plateforme centrale peut être sécurisée.
Le marchand peut avoir un mot de passe administrateur solide.
La double authentification peut être activée.
Le CMS peut être parfaitement à jour.
Si une application disposant d’autorisations importantes est compromise, elle devient elle-même une porte d’entrée.
Pourquoi les clés API sont-elles si sensibles ?
Une clé API ressemble rarement à quelque chose de spectaculaire.
Une longue chaîne de caractères.
Pas de formulaire de connexion.
Pas de mot de passe saisi manuellement.
Pas forcément de validation 2FA à chaque utilisation.
Mais techniquement, elle peut représenter une identité machine disposant de permissions importantes.
Selon les droits accordés, une application peut lire des clients, manipuler des commandes, récupérer des produits ou modifier certaines parties de la boutique.
La question de sécurité n’est donc pas uniquement :
« Qui possède un compte administrateur ? »
Elle doit également devenir :
« Quelles applications peuvent agir sur ma boutique et avec quels droits ? »
Et surtout :
« Est-ce que j’utilise encore réellement chacune d’entre elles ? »
Parce qu’une intégration oubliée depuis deux ans conserve parfois ses autorisations beaucoup plus longtemps que son utilité.
Shopify, WooCommerce et PrestaShop sont-ils concernés par le même risque ?
Pas par cet incident.
Mais par le principe de sécurité qu’il illustre, oui.
Shopify possède son écosystème d’applications.
WooCommerce repose sur des extensions et services externes.
PrestaShop dispose de modules, webservices et connexions API.
WordPress multiplie lui aussi les plugins et intégrations SaaS.
Le mécanisme technique varie d’une plateforme à l’autre, mais le problème de fond reste le même :
chaque extension du système étend aussi sa surface de confiance.
C’est une distinction importante avec les vulnérabilités classiques de modules.
Une extension peut être parfaitement à jour et ne contenir aucune vulnérabilité connue.
Si l’infrastructure de son éditeur ou ses identifiants d’accès sont compromis, elle peut malgré tout devenir le vecteur d’une attaque.
La maintenance du CMS reste donc indispensable.
Elle n’est simplement pas suffisante à elle seule.
Comment auditer les applications connectées à une boutique ?
Le premier travail est presque administratif.
Faire l’inventaire.
Applications installées, modules, comptes techniques, clés API, webservices, outils marketing, solutions de tracking, CRM, ERP, connecteurs logistiques, automatisations…
Puis poser quatre questions pour chaque accès :
- Est-il toujours utilisé ?
- Qui en est responsable ?
- Quelles permissions possède-t-il ?
- Peut-on réduire ces permissions ?
Le principe du moindre privilège consiste précisément à n’accorder à un service que les droits dont il a réellement besoin.
Une application chargée d’afficher un widget marketing n’a pas nécessairement besoin d’accéder à l’ensemble des informations clients.
Lorsqu’une plateforme permet de limiter les scopes d’une API, ces réglages ne sont donc pas de simples détails techniques.
Ils déterminent ce qu’un attaquant pourra faire si cette clé est un jour compromise.
Il faut également supprimer les intégrations inutilisées plutôt que de simplement les laisser dormir.
Une porte dont personne ne se sert reste une porte.
Le nouveau périmètre de la sécurité e-commerce
Les incidents récents montrent à quel point le périmètre de sécurité d’un site moderne s’est élargi.
Le CMS n’est plus seul.
Une boutique peut dépendre :
- d’un CDN ;
- d’une CMP ;
- d’une solution emailing ;
- d’un moteur de recherche ;
- d’une solution de paiement ;
- d’un outil de personnalisation ;
- d’un ERP ;
- d’un PIM ;
- d’un CRM ;
- de scripts marketing ;
- et parfois de dizaines d’API.
L’incident Ribon rappelle donc une chose assez inconfortable :
on peut parfaitement sécuriser son propre système et rester dépendant de la sécurité des systèmes auxquels on a accordé un accès.
C’est la logique même de la supply chain numérique.
Et elle explique pourquoi la maintenance d’une boutique moderne devrait inclure non seulement les mises à jour, mais également une revue régulière des accès tiers.
Le sujet devient d’autant plus important avec l’arrivée des agents IA capables d’interagir directement avec les systèmes e-commerce.
Nous l’avons déjà vu avec Shopify qui ouvre son checkout aux agents IA ou avec la nécessité de préparer les catalogues produits aux agents IA.
Plus les machines peuvent agir directement sur les systèmes commerciaux, plus une question devient fondamentale :
quelle machine a le droit de faire quoi ?
Que retenir de cet article ?
- Des identifiants API des applications Ribon et Ribon 1.5 ont été compromis à la suite d’un incident chez Fastr.
- L’activité malveillante documentée s’est déroulée entre le 13 et le 17 septembre 2026.
- Les identifiants ont été utilisés pour injecter des scripts dans un petit nombre de boutiques BigCommerce.
- Chez Master of Malt, des noms, emails, numéros de téléphone et adresses de livraison ont été consultés.
- Les mots de passe et informations de carte bancaire n’auraient pas été exposés par cet incident.
- Selon BigCommerce, sa plateforme elle-même n’a pas été compromise.
- L’incident illustre un risque de supply chain : compromettre un service autorisé peut permettre d’atteindre ses clients.
- Ce principe concerne potentiellement tous les écosystèmes utilisant applications, modules et API : BigCommerce, Shopify, WooCommerce, PrestaShop ou autres.
- Un audit de sécurité e-commerce devrait donc aussi inclure les applications connectées, leurs clés et leurs permissions.
Sources
BleepingComputer — BigCommerce alerts merchants of data breach linked to Ribon apps
0 commentaires