Détournement du checkout Shopify et gel des script tags : auditer vos scripts tiers avant la Cyber Week

Ce qui s'est passé en octobre

Le 10 octobre 2026, le développeur Roman Zipp clique sur « Paiement » dans une boutique Shopify connue et arrive sur une page qui ressemble au checkout Shopify, mais qui n'en est pas un. Les chercheurs ont remonté la redirection jusqu'à du code servi par des applications tierces de vitrine : un endpoint de configuration d'un éditeur d'applications renvoyait un script qui remplaçait le vrai checkout par une copie hébergée sur un domaine signalé comme biliing[.]top, et un cas similaire impliquant un second éditeur a été mis au jour la même semaine.

La fausse page capturait les données de carte, puis renvoyait l'acheteur vers le vrai checkout : la commande se finalisait normalement. Du point de vue du marchand, rien ne semblait anormal. De nouvelles activités étaient encore signalées le 18 octobre.

Pourquoi c'est plus important que d'habitude ce mois-ci

Trois raisons en font une priorité de novembre plutôt qu'un chantier de janvier :

1. Le pic de trafic multiplie l'exposition. Un script compromis actif pendant la semaine du Black Friday touche plus d'acheteurs en quelques jours qu'en un trimestre normal.
2. Les commandes paraissent légitimes. Comme la session volée se termine sur votre vrai checkout, vous ne verrez ni paiements échoués ni paniers abandonnés. Vous risquez de ne l'apprendre que par des rétrofacturations ou des plaintes clients, des semaines plus tard.
3. Les script tags sont gelés. Depuis le 1er octobre, les applications ne peuvent plus créer ni modifier de script tags de vitrine. Une application qui en dépend encore ne peut pas livrer rapidement un correctif par ce mécanisme.

Le calendrier des script tags, au même endroit

Le remplaçant est un bloc app embed livré via une extension d'application de thème, plus les web pixels pour le suivi. Attention : un app embed reste désactivé tant que le marchand ne l'active pas dans l'éditeur de thème. Shopify prévoyait un avertissement à l'installation pour les applications utilisant encore des script tags, mais l'a suspendu pour l'instant et indique qu'il réexaminera l'usage en janvier.

Un audit en quatre étapes à faire cette semaine

1. Faites le test du checkout en navigation privée. Ouvrez votre boutique dans une fenêtre privée, ajoutez un produit au panier et cliquez sur Paiement. Avant de saisir quoi que ce soit, regardez la barre d'adresse : ce doit être votre domaine ou checkout.shopify.com, jamais un hôte inconnu. Répétez sur mobile et depuis un tiroir de panier, car les scripts n'interceptent souvent qu'un seul point d'entrée.
2. Inventoriez chaque script de la vitrine. Listez toutes les origines de scripts externes chargées sur vos pages d'accueil, produit, collection et panier. Tout ce que vous ne pouvez pas associer à une application installée ou à un service connu est un signal d'alerte.
3. Associez les scripts aux applications et supprimez les orphelins. Les applications désinstallées laissent parfois du code dans les fichiers du thème. Cherchez les références <script src= et asset_url dans votre thème, et supprimez tout ce qui est lié à une application que vous n'utilisez plus.
4. Posez deux questions à chaque éditeur restant. Avez-vous migré des script tags vers un app embed ou un web pixel ? Et chargez-vous du code depuis un endpoint de configuration distant à l'exécution ? La configuration distante est précisément le chemin exploité en octobre.

Inventorier les scripts depuis la console du navigateur

Collez ce code dans la console sur n'importe quelle page de la vitrine. Il regroupe chaque script externe par origine, signale les scripts inline qui mentionnent le checkout et vérifie où pointent réellement le formulaire du panier et les liens de paiement :

// Inventaire des scripts de la vitrine : à coller dans la console DevTools
(() => {
  const ownHost = location.hostname;
  const trusted = [ownHost, "cdn.shopify.com", "checkout.shopify.com", "shop.app"];

  const byOrigin = {};
  document.querySelectorAll("script[src]").forEach((s) => {
    const url = new URL(s.src, location.href);
    (byOrigin[url.hostname] ||= []).push(url.pathname);
  });

  console.group("Origines des scripts externes");
  Object.entries(byOrigin)
    .sort((a, b) => b[1].length - a[1].length)
    .forEach(([host, paths]) => {
      const flag = trusted.some((t) => host.endsWith(t)) ? "" : "  <- à vérifier";
      console.log(`${host} (${paths.length})${flag}`);
    });
  console.groupEnd();

  const inlineCheckout = [...document.querySelectorAll("script:not([src])")]
    .filter((s) => /checkout/i.test(s.textContent)).length;
  console.log(`Scripts inline mentionnant "checkout" : ${inlineCheckout}`);

  const targets = [
    ...[...document.querySelectorAll('form[action*="cart"], form[action*="checkout"]')].map((f) => f.action),
    ...[...document.querySelectorAll('a[href*="checkout"]')].map((a) => a.href),
  ];
  console.group("Cibles du panier et du checkout");
  targets.forEach((t) => {
    const host = new URL(t, location.href).hostname;
    console.log(`${t}${trusted.some((x) => host.endsWith(x)) ? "" : "  <- HÔTE INATTENDU"}`);
  });
  console.groupEnd();
})();

C'est un instantané, pas une garantie. Un script malveillant peut ne réécrire le bouton qu'au clic, ou seulement pour certains visiteurs : combinez-le avec le test manuel du checkout et la surveillance décrite plus bas.

Pour les développeurs d'applications : retrouver vos propres script tags

Si vous développez ou maintenez une application Shopify, listez les script tags que votre application possède encore. La requête scriptTags exige le scope read_script_tags et ne renvoie que les tags créés par l'application appelante :

{
  "query": "query { scriptTags(first: 50) { nodes { id src displayScope cache createdAt } } }"
}

Pour chaque résultat, livrez le bloc app embed ou le web pixel équivalent, demandez aux marchands de l'activer dans l'éditeur de thème, puis supprimez l'ancien tag avec scriptTagDelete. N'attendez pas mars : un marchand qui installe votre application aujourd'hui n'obtient déjà plus aucun script tag fonctionnel.

Continuer à surveiller après l'audit

Un audit ponctuel détecte ce qui est présent aujourd'hui. Pour repérer un changement pendant la Cyber Week, planifiez une vérification :

• Récupérez vos pages clés toutes les heures et comparez la liste des origines de scripts externes à une liste approuvée.
• Déclenchez une alerte pour toute nouvelle origine, et pour tout formulaire de panier ou lien de paiement pointant hors de votre domaine ou de celui de Shopify.
• Journalisez le résultat pour disposer de preuves si vous devez plus tard enquêter sur un pic de rétrofacturations.

Nous construisons généralement cela sous forme d'un petit workflow n8n qui publie dans Slack ou par e-mail. Son coût d'exécution est quasi nul et il complète bien les alertes opérationnelles décrites dans notre article sur les alertes e-mail ops Shopify.

La place de Shopify Protect

L'Édition Automne '26 a introduit Shopify Protect, avec des règles anti-fraude testables sur l'historique et des réponses aux litiges rédigées par l'IA. Il aide sur la fraude au paiement, mais il n'inspecte pas le JavaScript exécuté sur votre vitrine. L'hygiène des scripts reste votre responsabilité. Nous présentons Protect dans notre tri de l'Édition Automne '26.

Comment Sentinu peut vous aider

Nous auditons les scripts de vitrine dans chaque mission d'optimisation de la vitesse Shopify, et nous migrons les applications sur mesure des script tags vers les app embeds et les web pixels dans le cadre du développement d'applications Shopify. Si vous voulez un regard extérieur avant le Black Friday, contactez-nous.

FAQ

Shopify lui-même a-t-il été piraté ?

Aucun rapport public ne l'indique. La campagne signalée exploitait du code chargé via des applications tierces de vitrine. Le checkout de Shopify était la destination finale, ce qui explique pourquoi les commandes paraissaient normales.

Comment savoir si ma boutique a été touchée ?

Faites le test du checkout en navigation privée et l'inventaire en console décrits plus haut. Si vous trouvez un hôte de paiement inattendu ou une origine de script inconnue, supprimez l'application concernée, contactez l'éditeur et le support Shopify, et examinez les rétrofacturations et plaintes clients récentes liées à des fraudes à la carte.

Mes applications cesseront-elles de fonctionner le 1er mars 2027 ?

Toute fonctionnalité d'application qui repose encore sur des script tags de vitrine cessera de se charger à cette date. Les applications passées aux blocs app embed ou aux web pixels continuent de fonctionner, mais vous devez activer l'app embed dans l'éditeur de thème.

Supprimer les script tags suffit-il à sécuriser ma boutique ?

Cela réduit le risque sans le supprimer. Les app embeds exécutent aussi du JavaScript sur votre vitrine. Le vrai contrôle consiste à savoir exactement quels scripts s'exécutent, à qui ils appartiennent et s'ils chargent du code depuis des endpoints distants.

Les vitrines headless ont-elles le même risque ?

Oui, si des scripts tiers sont chargés dans le frontend headless. Les vitrines Hydrogen et Next.js doivent appliquer le même inventaire, la même liste d'origines approuvées et la même surveillance.