Attaque de phishing du checkout Shopify : que s'est-il passé et comment vérifier votre boutique

L’attaque de phishing sur le checkout Shopify est une campagne, signalée pour la première fois le 10 octobre 2026, dans laquelle des applications tierces de vitrine (storefront) ont été manipulées pour charger du code qui redirigeait les acheteurs cliquant sur Paiement (Checkout) vers une fausse page de paiement. La fausse page capturait leurs coordonnées bancaires, puis les transmettait au véritable checkout de la boutique.

Statut, vérifié le 19 octobre 2026 : De nouvelles activités ont été signalées pas plus tard que le 18 octobre. Swym a déclaré dans une FAQ qu’une activité non autorisée commençant à 21:17 UTC a utilisé l’accès de l’application Wishlist Plus pour ajouter des scripts à certaines boutiques. L’entreprise a donc désactivé l’application pour tous les marchands et révoqué ses accès Shopify. Swym a depuis retiré cette FAQ, et sa page d’état (status page) indique toujours un incident en cours. Sur l’App Store, les fiches de Hulk Product Options, Swym Wishlist Plus, Selleasy, Boost AI Search & Filter et Privy affichent toutes « indisponible actuellement ». Boost et Privy n’ont pas lié la suspension de leurs fiches à cette campagne.¹²³

Points clés à retenir

• Depuis au moins le 10 octobre 2026, certains acheteurs ayant cliqué sur Paiement ont été redirigés vers un faux checkout qui a envoyé leurs coordonnées bancaires à un pirate, avant de les renvoyer vers la vraie page.
• HulkApps, Selleasy et Swym ont confirmé qu’un tiers non autorisé a modifié ce que leurs applications chargeaient sur certaines vitrines. Aucun n’a publié l’origine exacte du problème.
• Aucune source n’indique que le checkout ou les systèmes de Shopify eux-mêmes ont été piratés. Le code s’exécutait sur les pages de la vitrine, avant le chargement de la page de paiement.
• Lors de la première vague, le code est arrivé via les paramètres des applications, et non dans les fichiers du thème. Une recherche dans le code serait donc passée à côté. C’est le test en conditions réelles (live checkout test) qui permet de s’en assurer.
• Toute application qui charge du code sur votre vitrine est du code que quelqu’un d’autre peut modifier. Supprimer celles dont vous n’avez pas besoin réduit le risque définitivement.

Pourquoi vous pouvez nous faire confiance

Jacques possède plus de 15 ans d’expérience en développement, et nous avons passé plus de quatre ans à travailler dans le code des thèmes Shopify pour des centaines de marchands. Nous avons créé Fudge, un outil qui lit le vrai code du thème d’une boutique et peut tester une vitrine en direct dans un vrai navigateur.

Ceci n’est pas un rapport d’analyse légale (forensics). Chaque affirmation ci-dessous s’appuie sur la déclaration d’un fournisseur, la documentation de Shopify ou sur le développeur qui a découvert l’attaque. Nous précisons toujours lorsqu’une affirmation repose sur le rapport d’une seule personne.

---

Que s’est-il passé lors de l’attaque de phishing du checkout Shopify ?

Le développeur Roman Zipp l’a découverte par hasard le 10 octobre. Il faisait un achat sur la boutique Shopify d’un vendeur de claviers, a cliqué sur Commander, et son gestionnaire de mots de passe a essayé de remplir les mauvais champs sur une page qui ressemblait au checkout de Shopify. La barre d’adresse affichait un domaine qu’il ne connaissait pas.⁴

Il a répété l’opération dans une fenêtre de navigation privée avec des informations de test. Le formulaire a envoyé les données au serveur de l’attaquant, qui a répondu par un numéro de dossier, puis la page l’a redirigé vers le vrai checkout de la boutique.⁴

Il a remonté la piste du code jusqu’à Hulk Product Options et l’a signalé. Sa chronologie montre que le piratage a disparu de cette boutique 16 minutes après que Shopify ait fait remonter l’alerte en interne. Quelques jours plus tard, des marchands n’ayant jamais installé d’application HulkApps ont signalé le même faux checkout, et Selleasy ainsi que Swym ont confirmé des incidents de leur côté.⁴⁵⁶⁷

Chronologie

Date (2026)	Événement
22 juillet	Qikify découvre des redirections de checkout plantées dans les champs de configuration de deux de ses applications et les supprime le jour même. Ils traitent cela comme un cas distinct.8
10 octobre	Zipp trouve le faux checkout. HulkApps déclare plus tard que des configurations non autorisées ont atteint Hulk Product Options ce jour-là.49
13 octobre, de 07:47 à 15:00 UTC	Fenêtre d’incident de Selleasy, selon son avis envoyé à un marchand concerné.5
14 octobre, de 10:06 à 11:56 UTC	Swym indique que la configuration de Wishlist Plus a été modifiée sans autorisation. Les correctifs étaient totalement en ligne à 16:32 UTC.7
15 octobre	HulkApps publie une déclaration. Zipp indique que sept marchands l’ont contacté et qu’ils n’utilisaient pas tous HulkApps.94
17 octobre	Un porte-parole de Shopify fait un commentaire à iTnews.10
18 octobre, à partir de 21:17 UTC	Swym signale de nouvelles activités non autorisées utilisant l’accès de l’application, puis désactive l’application pour tous les marchands.1

---

Comment fonctionnait la redirection vers le faux checkout ?

Les attaquants n’ont jamais touché au checkout de Shopify. Ils ont détourné le clic qui y mène.

Les applications placent du code sur votre vitrine via les app embeds, que Shopify injecte juste avant la balise de fermeture </head> ou </body> de chaque page.¹¹ Le checkout est un monde à part : les applications qui l’étendent s’exécutent dans un environnement bac à sable (sandbox) isolé, sans accès à la page de checkout ni aux détails de paiement.¹² Nous couvrons ce sandbox dans notre guide sur l’extensibilité du checkout Shopify.

Ainsi, le code s’exécutait sur la page produit et le panier, attendait un clic ou tap sur Commander, et envoyait l’acheteur ailleurs avant que le checkout de Shopify ne puisse se charger.

Méthode 1 : du code caché dans les paramètres de l’application

De nombreuses applications de vitrine incluent un petit script qui, à chaque chargement de page, interroge les serveurs du fournisseur pour obtenir les paramètres de la boutique. Lors de la première vague, ces paramètres étaient la charge utile (payload).

• HulkApps : le script de l’application lui-même provenait du CDN de Shopify et était propre. Zipp a trouvé environ 22,7 Ko de code JavaScript supplémentaire dans un champ de code personnalisé des paramètres téléchargés depuis l’API d’HulkApps.⁴
• Selleasy : leur avis aux marchands indique qu’un individu externe s’est introduit dans l’un des outils internes de Selleasy et a planté un script dans les paramètres Selleasy de plusieurs boutiques.⁵
• Swym (14 octobre) : Swym décrit une modification non autorisée de la configuration de l’application. Le développeur Dan Sutherland, qui a enquêté sur une boutique touchée, signale que le script d’attaque se trouvait à l’endroit où le texte du bouton « Ajouter à la Wishlist » aurait dû être.⁷¹³
• Qikify (Juillet) : du code a été planté dans des champs HTML personnalisables des paramètres de l’application, et Qikify affirme que rien n’a été écrit dans les thèmes des marchands.⁸

Une recherche dans le code du thème n’aurait trouvé aucun de ces scripts. Le code résidait sur les serveurs du fournisseur et n’apparaissait que dans le navigateur de l’acheteur.

Méthode 2 : utiliser l’accès de l’application à la boutique

L’incident du 18 octobre concernant Swym est différent. Swym indique que l’activité a utilisé l’accès propre de l’application Wishlist Plus aux boutiques des marchands, et non les comptes du personnel, pour ajouter des scripts tentant de rediriger les acheteurs. Ils demandent aux marchands de vérifier dans les fichiers de leur thème les modifications apportées par l’application Swym et d’y rechercher checkout-guard.¹

Cela rend une recherche dans le thème tout aussi pertinente. Nous montrons comment faire ci-dessous.

Ce que le code faisait dans le navigateur de l’acheteur

D’après le code capturé par Zipp :⁴

1. Il écoutait le tap ou le clic sur Commander.
2. Il chargeait un faux checkout sur un domaine externe.
3. Les détails de la carte partaient vers le serveur de l’attaquant.
4. L’acheteur était redirigé vers le vrai checkout pour payer à nouveau, de sorte que la commande passait quand même.
5. Il plaçait __ctf_shim_handoff_done_v1 dans le Session storage pour ne pas se déclencher deux fois pour le même acheteur.

HulkApps ajoute que la redirection échouait lors de certaines visites et que certains navigateurs la bloquaient.⁹ En résumé, un propriétaire de boutique testant son propre checkout pouvait facilement ne rien remarquer.

Domaines identifiés à ce jour

Ne visitez pas ces adresses. Chacune est écrite avec des crochets pour ne pas être cliquable.

Domaine	Signalé par
biliing[.]top	Zipp, et des marchands sur le fil de la Communauté45
checkout-confirm[.]top	Zipp4
order-confirm[.]top	Zipp4
account-confirm[.]top	Dan Sutherland, un membre de la Communauté, et Swym (vu dans des attaques similaires)1351
billing-confirm[.]top	Dan Sutherland13
checkout-guard[.]top	Swym (lors de son incident du 18 octobre)1
checkout-secure[.]top	Swym (vu dans des attaques similaires)1

Comment les attaquants sont-ils entrés ?

Personne ne l’a dit publiquement. HulkApps parle d’un « exploit ». Selleasy mentionne un outil interne. Swym décrit une modification non autorisée, puis l’utilisation de l’accès de l’application.⁹⁵¹

Zipp liste quatre possibilités pour le cas d’HulkApps et n’en a confirmé aucune : le compte HulkApps d’un marchand, le compte d’un employé d’HulkApps, HulkApps eux-mêmes, ou une autre application altérant la configuration.⁴

Niveau de certitude	Déclarations
Confirmé par le fournisseur	HulkApps (10 octobre), Selleasy (13 octobre) et Swym (14 et 18 octobre) affirment qu’un tiers non autorisé a modifié ce que leurs applications chargeaient sur certaines boutiques.
Signalé par une personne, non confirmé	Boost et Privy comme vecteurs de livraison. La charge utile du 14 octobre de Swym cachée dans un texte de bouton et restant en cache dans le navigateur. Un cas en août chez Hextom.1345
Non public	Le point d’entrée, le nombre de boutiques et d’acheteurs touchés, le nombre de cartes capturées, et si les incidents sont liés.

---

Quelles applications Shopify étaient impliquées ?

Rien ne prouve qu’un de ces fournisseurs a écrit le code malveillant. HulkApps, Selleasy, Swym et Qikify affirment que les attaquants ont utilisé leurs applications pour le distribuer.

Hulk Product Options a-t-il été piraté ? Ce que dit HulkApps

Selon HulkApps, un exploit a glissé des configurations non autorisées dans Hulk Product Options le 10 octobre, dans le cadre d’une attaque plus large ciblant plusieurs applications Shopify. HulkApps retrace toutes les redirections liées à ses applications à un seul endroit, l’extension de thème Hulk Product Options. Shopify a désactivé cette extension par précaution, puis l’a restaurée plus tard.⁹

L’entreprise a engagé une société de sécurité indépendante, renforcé l’authentification et informé les marchands qu’ils n’avaient pas besoin de désinstaller l’application. La page de l’App Store indiquait toujours « indisponible » le 19 octobre.⁹³

Selleasy (Logbase)

Logbase décrit le 13 octobre comme une attaque délibérée et planifiée qui a injecté un script dans certaines des boutiques servies par Selleasy. Ils n’ont trouvé aucune preuve de violation de leur backend ou base de données, et affirment que Shopify a confirmé que le code a été retiré le même jour.⁶

Leur avis aux marchands concernés ajoute la fenêtre temporelle, de 07:47 à 15:00 UTC, et précise qu’ils ont verrouillé le paramètre Custom JS pour qu’aucun outil ni API ne puisse le modifier.⁵

Swym Wishlist Plus (Swym)

Swym a publié deux incidents :

1. 14 octobre : une modification de configuration a provoqué le chargement d’un script sur certaines vitrines, ce qui a pu envoyer les acheteurs vers un faux checkout. Swym a renouvelé ses clés d’API (API secrets) et ajouté des règles de sanitisation. L’entreprise demande aux marchands de signaler tout événement suspect survenu entre 10h06 et 16h32 UTC.⁷
2. 18 octobre : de nouvelles activités ont utilisé l’accès de l’application pour ajouter des scripts à certaines boutiques. Swym a désactivé l’application pour tous les marchands, révoqué ses accès Shopify et affirme ne pas pouvoir encore confirmer ou infirmer un quelconque impact sur les acheteurs.¹

Swym a publié les détails du 18 octobre dans une FAQ le 19 octobre et l’a retirée plus tard dans la journée. Sa page d’état décrit toujours un incident en cours et, le 19 octobre à 15h30 UTC, indiquait que Swym se préparait à déployer des correctifs.¹²

Non confirmé : Boost AI Search & Filter et Privy

Aucun de ces fournisseurs n’a lié ses problèmes à cette campagne, et une page App Store indisponible ne prouve pas qu’une application a été compromise. Les deux pages étaient indisponibles le 19 octobre.³

• Boost : sa page de statut indique que l’extension de thème de l’application a été désactivée pour toutes les boutiques le 17 octobre et que Shopify l’a réactivée le lendemain. Elle décrit un incident affectant les fonctionnalités de l’application et ne mentionne pas la sécurité.¹⁴ Un commentaire sur le fil de la Communauté Shopify affirme que la même redirection est apparue le 17 octobre sur une boutique sur laquelle il travaille, via l’application Boost.⁵
• Privy : sa page de statut signale une panne de ses pop-ups (on-site displays) du 17 au 18 octobre, sans mention de la sécurité.¹⁵ Un commentaire sur l’article de Zipp cite Privy comme la source sur leurs boutiques.⁴

Plus tôt : l’incident de juillet de Qikify

L’avis de Qikify couvre le 22 juillet 2026, date à laquelle certains checkouts de ses applications Sticky Add to Cart et Mega Menu ont été détournés vers une page frauduleuse via les champs de configuration des applications. Qikify a réinitialisé l’authentification de toutes ses applications le 29 juillet, et les deux étaient de retour sur l’App Store le 21 août.⁸

L’article de Zipp liste également un cas en août chez Hextom. Hextom n’a publié aucun avis et nous n’avons pas pu le vérifier.

---

Shopify a-t-il été piraté ? Ce que Shopify a dit

Rien de publié à ce jour ne l’indique. Ni Shopify ni aucune déclaration de fournisseur ne décrit une violation des systèmes internes de Shopify.

Shopify n’a pas publié d’article ou d’entrée de changelog concernant la campagne en date du 19 octobre. Un porte-parole a déclaré à iTnews : « Quand une application n’est pas à la hauteur, nous agissons. » Shopify explique que cela peut impliquer le retrait de l’application, et dans ce cas, demande au développeur de l’application de contacter directement les marchands concernés.¹⁰ Sa page de politique des Partenaires liste aussi des options plus fortes, y compris la suppression de l’application des boutiques des marchands et la coupure de son accès API.¹⁶

Shopify a agi sur des signalements individuels. Une marchande australienne touchée via Selleasy s’est vu conseiller de garder sa boutique fermée pendant que Shopify enquêtait, et a déclaré à iTnews le 19 octobre que Shopify lui avait donné le feu vert pour rouvrir.¹⁰⁵

---

Comment vérifier si votre boutique a cette fausse redirection de checkout ?

Dupliquez votre thème en ligne avant de modifier quoi que ce soit (Boutique en ligne, le menu … sur votre thème, Dupliquer). Ensuite, suivez ces étapes dans l’ordre.

1. Faites le test du checkout en cinq minutes

C’est la vérification qui aurait détecté la première vague.

• Ouvrez une nouvelle fenêtre de navigation privée. Cela permet de partir avec un stockage de navigateur vide, ce qui compte doublement : le script se déclenchait une seule fois par session, et un développeur a signalé que les paramètres de Swym étaient en cache dans le navigateur et pouvaient maintenir la charge utile en vie même après la désactivation de l’application.¹³
• Ajoutez un produit au panier et utilisez le bouton Commander standard au lieu d’une option express comme Shop Pay ou PayPal.
• Lisez la barre d’adresse au moment où la page de checkout apparaît. Le checkout de Shopify s’exécute sur votre propre domaine, ou sur votre adresse myshopify.com si vous n’en avez pas connecté un. Shopify a mis cela en place en 2017.¹⁷ Tout autre domaine à ce stade est un drapeau rouge. N’entrez pas de détails de carte. Traitez cela comme un incident.
• Fermez la fenêtre, ouvrez-en une nouvelle et répétez depuis le tiroir du panier. Qikify indique que sa redirection Sticky Add to Cart se déclenchait quand les acheteurs cliquaient sur Commander depuis le tiroir du panier.⁸
• Répétez une fois de plus sur votre téléphone.

Les pages de carte de votre fournisseur de paiement ou de votre banque, comme 3-D Secure, peuvent apparaître plus tard dans le processus. Le drapeau rouge est un domaine différent au moment où la page de checkout se charge pour la première fois.

2. Trouvez toutes les applications qui peuvent exécuter du code sur vos pages

• Paramètres > Applications liste vos applications installées.¹⁸ Notez Hulk Product Options, Swym Wishlist Plus et Selleasy (incidents confirmés), et si vous utilisez Boost AI Search & Filter ou Privy. Ouvrez chaque application pour voir sa carte Extensions, qui montre ce qui est actif et où.¹⁸
• Boutique en ligne > Personnaliser (ou Modifier le thème), puis l’icône App embeds dans la barre latérale, affiche chaque app embed qui est activé.¹⁹ Chacun peut charger du code sur n’importe quelle page.

3. Cherchez les marqueurs connus dans votre thème

Allez dans Boutique en ligne, ouvrez le menu … sur votre thème en ligne et choisissez Modifier le code. Le bouton de recherche dans la barre latérale gauche cherche dans tous les fichiers du thème.²⁰ Pour une visite guidée de l’éditeur, consultez comment modifier votre thème Shopify.

Recherchez :

• Chaque domaine du tableau ci-dessus, sans les crochets (par exemple biliing.top)
• checkout-guard, que Swym demande aux marchands de chercher¹
• __ctf_, le préfixe des clés de stockage que Zipp a trouvé⁴

Chercher uniquement .top vous submergera de résultats CSS et JavaScript inoffensifs.

Une recherche propre ne couvre que le thème. Le code qui arrive via les paramètres d’une application n’y apparaîtra jamais.

4. Facultatif : regardez dans les outils de développement du navigateur

Si vous connaissez les DevTools de Chrome, ouvrez-les pendant un checkout de test. Cherchez les clés __ctf_ sous Application > Stockage de session (Session storage). Dans l’onglet Réseau (Network), vérifiez chaque domaine contacté par vos pages produit et panier, et assurez-vous de connaître le propriétaire de chacun d’eux.

5. Écoutez vos clients

Parce que la fausse page transférait les acheteurs vers le vrai checkout, les commandes peuvent paraître totalement normales. Les signaux viendront plutôt de vos clients : un e-mail au support concernant une page de paiement étrange, ou un signalement de fraude à la carte peu après avoir passé commande chez vous.

---

Fudge peut-il vérifier si ma boutique a cette redirection de phishing du checkout ?

En partie. Fudge peut exécuter le test de checkout en direct qui aurait détecté la première vague, et chercher dans votre thème les marqueurs du 18 octobre. Mais il ne peut pas voir les serveurs des fournisseurs ni prouver qu’aucune carte n’a été interceptée.

Ce que Fudge peut vérifier

• Le test en direct, dans un vrai navigateur. Fudge ouvre votre boutique publique, ajoute un produit, clique sur Commander depuis la page panier et le tiroir du panier, et enregistre chaque page sur laquelle il atterrit, chaque domaine que la page contacte, et ce que ces requêtes retournent. C’est là que le code caché dans les paramètres des applications se révèle. C’est la même technologie derrière notre analyse pas à pas du flux de checkout.
• La recherche dans le thème. Fudge peut chercher dans chaque fichier de votre thème en ligne les domaines et marqueurs listés plus haut, et lister les app embeds qui sont activés. Voir notre investigation du code du thème.
• Un chemin de reconstruction sûr. Il peut désactiver un app embed suspect dans une copie brouillon de votre thème pour le tester. Si vous avez déjà vu une redirection, n’attendez pas de faire un brouillon : désactivez l’app embed sur votre thème en ligne tout de suite.

Ce qu’une vérification Fudge ne peut pas prouver

• Il ne peut pas lister vos applications installées ni lire les paramètres dans l’admin propre de l’application.
• Il ne peut pas voir les serveurs des fournisseurs ou les logs, ni vous dire si une carte a été capturée.
• Il s’exécute depuis un navigateur cloud situé à un endroit précis. Personne ne sait si ce code ignorait les navigateurs automatisés ou certains pays, et il échouait déjà lors de certaines visites.
• Il ne peut pas gérer la crise à votre place : le Support Shopify, votre processeur de paiement et vos clients.

Par conséquent, le résultat honnête d’une vérification propre est : aucune redirection ni aucun marqueur connu n’ont été vus lors de ce test, à cet instant. Ce n’est pas : votre boutique n’a jamais été touchée.

Prompt : demander à Fudge de lancer la vérification

Copiez ceci dans Fudge :

Effectue un contrôle de sécurité en lecture seule de ma boutique Shopify en ligne pour détecter la redirection de phishing de checkout d’octobre 2026. Ne modifie, ne crée de brouillon ni ne publie rien. Ne saisis pas de détails de paiement, et ne soumets aucun formulaire sur une page hors du domaine de ma boutique.

1. Sur ma boutique en ligne, utilise un agent de navigateur distinct pour chaque test afin que chacun démarre avec un stockage vide. Aux tailles mobile et bureau, ouvre une page produit, ajoute-le au panier, et clique sur le bouton principal Commander, une fois depuis la page panier et une fois depuis le tiroir du panier. Signale chaque URL sur laquelle le navigateur atterrit, et dis-moi immédiatement si elle quitte le domaine de ma boutique ou l’adresse myshopify.com avant le chargement de la page de checkout.
2. Liste tous les domaines externes qui chargent des scripts ou reçoivent des requêtes sur les pages produit et panier, groupés par l’application ou le service auquel ils appartiennent. Signale tout domaine se terminant en .top et toute réponse contenant une redirection.
3. Vérifie le Session storage et le Local storage pour des clés commençant par __ctf_ et, si possible, quel script les a créées.
4. Cherche dans chaque fichier de mon thème en ligne biliing.top, checkout-confirm.top, order-confirm.top, account-confirm.top, billing-confirm.top, checkout-guard, checkout-secure.top et __ctf_, plus tout script qui envoie les acheteurs vers un autre domaine quand ils cliquent sur Commander.
5. Liste les app embeds activés dans mon thème en ligne et l’application derrière chacun d’eux.

Pour chaque découverte, donne le fichier ou l’URL, ce que fait le code, et ton niveau de certitude. Termine en listant ce que cette vérification n’a pas pu voir.

---

Que faire si votre boutique est touchée ?

D’abord, limitez les dégâts

• Capturez les preuves. Prenez une capture d’écran de la fausse page avec son adresse visible, copiez l’URL complète, et notez l’heure. Dans les DevTools, vous pouvez sauvegarder l’onglet Network (Réseau) sous forme de fichier HAR. Les fichiers HAR peuvent contenir vos cookies de connexion, donc ne les partagez qu’avec le Support Shopify ou le fournisseur de l’application.
• Désactivez le code. Désactivez l’intégration de l’application sous App embeds et sauvegardez, ou désinstallez l’application.¹⁹ Désinstaller ne supprime pas toujours tout ce qu’une application a ajouté à votre thème, alors vérifiez aussi le thème.²¹ Notre guide sur comment supprimer le code résiduel des applications vous explique comment faire.
• Testez à nouveau dans une nouvelle fenêtre de navigation privée. Les paramètres en cache peuvent survivre à la désactivation de l’application.¹³

Ensuite, signalez-le

• Le fournisseur de l’application : obtenez des informations par écrit : ce qui a été injecté, quand cela a été actif sur votre boutique, et leur déclaration publique.
• Le Support Shopify : envoyez vos preuves et soyez prêt à ce que Shopify suggère de fermer la boutique pendant leur enquête, comme ils l’ont fait pour au moins un marchand.⁵
• Votre processeur de paiement : pour Shopify Payments, signalez-le dans votre ticket au Support. Pour toute autre passerelle, contactez-les directement. Des cartes ont pu être copiées même sur des commandes qui se sont terminées normalement.
• Le domaine : Zipp a signalé les domaines qu’il a trouvés à Google Safe Browsing et URLhaus, ce qui aide les navigateurs à commencer à avertir les acheteurs.⁴

Enfin, fermez les portes

• Changez votre mot de passe Shopify et vos mots de passe pour le tableau de bord de chaque fournisseur d’application, et activez l’authentification en deux étapes.²²
• Sous Paramètres > Utilisateurs et autorisations, filtrez sur Collaborateurs et supprimez tout accès partenaire dont vous n’avez pas besoin. Générer un nouveau code de demande collaborateur annule l’ancien.²³
• Révisez quelles applications et outils d’IA ont accès à votre boutique, comme le suggère Zipp.⁴ Cela inclut Fudge.
• Demandez à un avocat et à votre processeur de paiement si vous devez informer les acheteurs ou les régulateurs. Swym renvoie les marchands vers les lois sur la notification des violations et la protection des données, et vers leur accord avec le processeur de paiement.⁷ Ceci n’est pas un avis juridique.

Que dire aux clients qui posent la question : votre vrai checkout se trouve sur votre propre domaine. S’ils ont vu une adresse différente au moment de payer, ils doivent appeler l’émetteur de leur carte au sujet de la carte. Abstenez-vous de faire des promesses sur les remboursements tant que votre processeur de paiement n’a pas examiné votre cas.

---

Comment réduire les risques liés aux applications de la vitrine ?

Chaque application qui charge du code sur votre vitrine est un code que quelqu’un d’autre peut modifier. Cela inclut les applications en qui vous avez confiance.

Quand une application récupère ses paramètres depuis les serveurs du fournisseur à chaque chargement de page, ce qui s’exécute sur votre boutique peut changer sans la moindre modification de votre thème. Rien n’apparaît dans les fichiers de votre thème ou son historique. Vous le découvrez quand un client le découvre.

Shopify restreint la façon dont les applications chargent du code. Depuis le 1er octobre 2026, les applications ne peuvent plus créer de nouvelles balises de script (script tags), et Shopify arrêtera de charger les balises de script de vitrine le 1er mars 2027.²⁴ Cela laisse les app embeds comme la principale méthode supportée, et vous pouvez les examiner dans un seul panneau. Mais cela n’empêche pas un app embed d’aller chercher du nouveau code chez son fournisseur, et une application ayant accès au thème peut toujours modifier les fichiers du thème.

Posez trois questions pour chaque app embed

1. L’utilisons-nous toujours ? Si non, désinstallez-la et nettoyez ce qu’elle a laissé derrière elle.
2. A-t-elle un paramètre JavaScript personnalisé ou HTML personnalisé ? Ouvrez-le et assurez-vous de reconnaître tout ce qu’il contient. Zipp a trouvé la charge utile d’HulkApps dans un champ JavaScript personnalisé, Selleasy a verrouillé son paramètre Custom JS après l’attaque, et Qikify nomme deux champs de contenu HTML.⁴⁵⁸
3. Votre thème pourrait-il faire ce travail lui-même ?

Intégrez ce que vous pouvez directement dans votre thème

Certaines des tâches accomplies par ces applications peuvent être directement intégrées dans votre thème. Le code natif réside dans vos fichiers de thème, ne change que lorsque quelqu’un les édite, et n’importe quel développeur peut le lire. Il n’est pas invulnérable : une application avec accès au thème peut toujours le modifier, c’est pourquoi Swym demande aux marchands de vérifier leurs fichiers de thème. Mais une modification apparaîtra lors d’une recherche de code.

• Les options de produits comme la gravure de texte, les notes cadeaux ou les pastilles de couleurs (swatches) peuvent utiliser des variantes et des line item properties. Les options qui modifient le prix nécessitent des variantes ou un produit additionnel séparé. Notre guide sur les configurateurs de produits en couvre les bases.
• Les ventes incitatives (upsells) et ventes croisées dans le panier peuvent utiliser les recommandations de produits natives de Shopify dans une section du panier. Voir comment ajouter des upsells dans le panier Shopify.
• Les offres groupées (bundles) peuvent souvent utiliser les bundles natifs de Shopify. Nous avons comparé les deux dans bundles Shopify natifs vs applications de bundles.

Certaines applications méritent leur place. Une wishlist qui se synchronise entre appareils ou une recherche sur un grand catalogue nécessite généralement un backend. Gardez celles-ci, désactivez tous les paramètres de code personnalisé que vous n’utilisez pas, et relancez le test du checkout après chaque mise à jour.

Avec Fudge, la méthode native commence par un prompt comme ceci :

Hulk Product Options affiche actuellement ces options sur mes pages produits : [texte de gravure, max 20 caractères ; emballage cadeau oui/non, +5 $]. S’ils s’affichent toujours sur ma page produit en ligne, vérifie-les là aussi. Recrée-les en code de thème natif et enregistre chaque choix comme une line item property pour qu’elle apparaisse sur la commande. Pour les options qui modifient le prix, explique les approches et les compromis avant de développer. Travaille dans un thème brouillon pour que je puisse tester avant de supprimer l’application.

Fudge est aussi une application ayant accès à votre thème, donc le même conseil s’applique à nous : n’accordez que l’accès que vous utilisez, et passez-le en revue. Les modifications que vous demandez à Fudge vont dans une copie brouillon de votre thème, et aucune d’elles n’atteint votre boutique en ligne avant que vous ne les ayez examinées et publiées dans l’éditeur de boutique Shopify.

---

La conformité PCI de Shopify couvre-t-elle cela ?

Shopify est certifié conforme PCI DSS de niveau 1.²⁵ Selon notre interprétation, cette certification concerne la plateforme et le checkout de Shopify. Elle ne peut pas garantir ce que fait un script tiers sur votre page produit avant que l’acheteur n’y arrive.

Le PCI Security Standards Council a un nom pour ce schéma, l’écrémage à double saisie (double-entry skimming) : un faux formulaire de paiement s’affiche d’abord, puis l’acheteur entre de nouveau ses informations sur le vrai.²⁶ Ses exigences en matière de scripts pour les pages de paiement, 6.4.3 et 11.6.1, sont entrées en vigueur le 31 mars 2025, mais la FAQ du Council indique que la vérification SAQ A associée vise les marchands qui intègrent un formulaire de paiement sur leurs propres pages, pas ceux qui redirigent les acheteurs vers la page d’un fournisseur.²⁷²⁸ La FAQ ne nomme pas Shopify, donc demandez à votre acquéreur comment un checkout hébergé par Shopify est classé pour votre boutique.

---

FAQ

Footnotes

1. Swym, “Wishlist Plus Security Precaution: Frequently Asked Questions”, publiée le 19 octobre 2026 sur getswym.com/resources/wishlist-plus-incident-faq. Nous l’avons consultée ce matin-là. Swym a supprimé la page plus tard dans la même journée. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰

2. Page d’état de Swym, consultée le 19 octobre 2026, incluant sa mise à jour de 15h30 UTC. ↩ ↩²

3. Fiches de l’App Store Shopify pour Hulk Product Options, Swym Wishlist Plus, Selleasy, Boost AI Search & Filter et Privy, consultées chacune le 19 octobre 2026. ↩ ↩² ↩³

4. Roman Zipp, Shopify shops hit with ongoing Checkout Hijack attack, publié le 10 octobre 2026, mis à jour le 16 octobre 2026, incluant les commentaires des lecteurs jusqu’au 17 octobre. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷

5. Communauté Shopify, URGENT: checkout phishing redirect - anyone else affected?, du 15 au 17 octobre 2026, incluant l’avis de Selleasy partagé par l’auteur original. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²

6. Logbase, Statut du service Selleasy : incident du 13 octobre, dernière mise à jour le 16 octobre 2026. ↩ ↩²

7. Swym, Mise à jour sur l’incident de sécurité, 16 octobre 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵

8. Qikify, Avis d’incident de sécurité, dernière mise à jour le 21 août 2026, avec une note ajoutée le 10 octobre 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵

9. Déclaration de HulkApps dans les commentaires de l’article de Zipp, 15 octobre 2026, et commentaire de HulkApps sur le post LinkedIn de Dan Sutherland, 15 octobre 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

10. Juha Saarinen, Shopify tells Australian store to stay shut after hijacked extensions divert shoppers, iTnews, 16 octobre 2026, mis à jour les 17 et 19 octobre 2026. ↩ ↩² ↩³

11. Documentation développeur Shopify, Configurer les extensions d’applications de thème (theme app extensions). ↩

12. Documentation développeur Shopify, Extensions d’interface du checkout (Checkout UI extensions), section Sécurité. ↩

13. Dan Sutherland, Post LinkedIn sur une redirection de phishing du checkout Shopify, 14 octobre 2026. Analyse d’un développeur sur une boutique, non confirmée par Swym. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

14. Page d’état de Boost Commerce, incident du 17 au 18 octobre 2026, consultée le 19 octobre 2026. ↩

15. Page d’état de Privy, affichant une panne du 17 au 18 octobre 2026, consultée le 19 octobre 2026. ↩

16. Centre d’aide Shopify, Application des politiques du Programme de partenaires de Shopify. ↩

17. Shopify, Introducing Store Checkout On Your Own Business Domain, 14 juillet 2017. ↩

18. Centre d’aide Shopify, Gestion des applications. ↩ ↩²

19. Centre d’aide Shopify, Étendre votre thème avec des applications. ↩ ↩²

20. Centre d’aide Shopify, Modification du code du thème. ↩

21. Centre d’aide Shopify, Désinstallation d’applications. ↩

22. Centre d’aide Shopify, Authentification en deux étapes pour les utilisateurs. Les boutiques Shopify Plus peuvent exiger une méthode de connexion sécurisée pour tous les utilisateurs. ↩

23. Centre d’aide Shopify, Comptes collaborateurs. ↩

24. Documentation développeur Shopify, Balises de script de vitrine (Storefront script tags). ↩

25. Shopify, Conformité PCI. ↩

26. PCI Security Standards Council, Payment Page Security and Preventing E-Skimming, supplément d’information v1.0, mars 2025, section “Double-Entry Skimming”. Annoncé ici, 10 mars 2025. ↩

27. PCI Security Standards Council, Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A, 30 janvier 2025. ↩

28. PCI Security Standards Council, FAQ 1588, février 2025. ↩