Vous n’avez pas besoin d’être ingénieur pour exploiter une boutique sûre. Mais quelques mécanismes techniques décident désormais si une attaque réussit ou échoue. Vous les voyez dans les avis sur les applications, les questionnaires de sécurité et les annonces de Shopify. Comprendre leur fonctionnement vous aide à poser aux éditeurs d’applications des questions bien plus précises.
Chaque technologie ci-dessous est expliquée simplement : ce qu’elle fait, ce qu’elle bloque, et où elle s’arrête.
- Les passkeys suppriment le mot de passe de l'attaque la plus courante, le phishing.
- Les bacs à sable expliquent pourquoi les pixels de suivi et Shopify Functions ne peuvent pas lire votre paiement.
- SRI et CSP protègent contre les fichiers falsifiés, mais pas contre le code livré comme « réglages » par un éditeur de confiance, la méthode utilisée lors du détournement d'octobre 2026.
- Aucune technologie seule ne suffit. La vraie protection vient de couches combinées et d'un nombre réduit d'applications, bien choisies.
Illustration conceptuelle : passkeys, bacs à sable et jetons signés protégeant une boutique en ligne moderne.
Fait partie du pôle thématiqueExplorer le pôle Sécurité Shopify →
1. Passkeys et clés de sécurité (WebAuthn)
Ce qu’elles font : vous vous connectez avec votre appareil (empreinte digitale, reconnaissance faciale ou code PIN) ou avec une clé matérielle physique, au lieu d’un mot de passe. La clé privée ne quitte jamais votre appareil.
Ce qu’elles bloquent : le phishing. Une passkey est liée de façon cryptographique à la véritable adresse du site, donc une fausse page « connexion Shopify » ne peut pas l’utiliser, même si la copie est identique. C’est encore plus important aujourd’hui, puisque les outils d’IA rédigent des e-mails de phishing très convaincants.
Où elles s’arrêtent : un ordinateur portable volé et déverrouillé, ou un attaquant que vous invitez vous-même comme collaborateur.
Sur Shopify : prises en charge pour l’authentification en deux étapes du personnel, et pour les clients de Shop Pay.
2. Jetons signés et à courte durée de vie (OAuth et échange de jetons)
Ce qu’ils font : au lieu de s’appuyer sur un mot de passe permanent, une application reçoit un jeton cryptographique signé par Shopify qui prouve pour quelle boutique elle agit. Les jetons à courte durée de vie expirent rapidement et doivent être renouvelés régulièrement.
Ce qu’ils bloquent : les requêtes rejouées ou falsifiées, et les dégâts durables si un jeton fuit.
Où ils s’arrêtent : les jetons de longue durée que vous créez pour des applications personnalisées ou des agences. Vous devez les traiter comme une clé maîtresse.
3. Périmètres à moindre privilège
Ce qu’ils font : chaque application déclare explicitement ce qu’elle peut lire ou écrire : produits, commandes, clients ou thèmes.
Ce qu’ils bloquent : une application (ou un attaquant qui la contrôle) qui dépasse son rôle prévu. Une application de menu n’a aucune raison de lire les commandes clients ; une application d’avis n’a aucune raison de modifier votre thème.
Où ils s’arrêtent : les périmètres limitent l’accès aux API côté serveur. Ils ne limitent pas ce que fait le script d’une application dans le navigateur de l’acheteur une fois chargé sur la page.
4. Bacs à sable
Ce qu’ils font : ils exécutent du code dans un environnement isolé, sans accès au reste de la page ni au système sous-jacent.
- Pixels web : les pixels d’applications s’exécutent dans un bac à sable strict (un web worker sans accès à la page) ; les pixels personnalisés s’exécutent dans une iframe isolée qui ne peut pas atteindre la page principale.
- Shopify Functions : modules WebAssembly soumis à des limites strictes d’instructions, de mémoire et d’entrées ; aucun accès réseau, sauf pour les applications personnalisées des forfaits Enterprise.
Ce qu’ils bloquent : un script de suivi qui lit les champs de carte bancaire, ou une fonction de remise qui appelle un serveur externe.
Où ils s’arrêtent : les scripts normaux de la vitrine, y compris la plupart des blocs d’intégration d’applications, ne sont pas isolés. Ils ont un accès complet à la page.
5. Content Security Policy (CSP)
Ce qu’elle fait : un en-tête HTTP qui indique au navigateur de quels domaines une page peut charger des scripts, vers quels domaines elle peut se connecter, et quels domaines peuvent l’intégrer dans une frame.
Ce qu’elle bloque : les scripts chargés depuis des domaines inconnus, et les attaques par détournement de clic (Shopify exige que les applications définissent frame-ancestors sur leurs pages d’administration).
Où elle s’arrête : une boutique qui utilise beaucoup d’applications a besoin d’une liste d’autorisation étendue, et le code malveillant qui s’exécute depuis un domaine approuvé reste autorisé. La CSP reste la plus efficace sur des pages petites et strictement contrôlées, comme le paiement.
6. Subresource Integrity (SRI)
Ce qu’elle fait : vous associez une empreinte cryptographique (hash) à une balise script ; le navigateur bloque le fichier si son contenu a changé.
Ce qu’elle bloque : un fichier falsifié hébergé sur un CDN.
Où elle s’arrête : les fichiers qui changent souvent de façon légitime, et le code qui arrive sous forme de données. Lors du détournement d’octobre 2026, le fichier de l’application sur le CDN de Shopify était propre. Le code malveillant venait de l’API de réglages de l’éditeur. La SRI n’aurait rien changé. La documentation de MDN souligne ces limites.
7. PCI DSS 4.0 : règles pour les scripts des pages de paiement
Qu’est-ce que c’est : la norme de sécurité du secteur des cartes de paiement. Deux exigences récentes visent spécifiquement le « e-skimming » (vol de données de carte par script malveillant) :
- 6.4.3 : tenir un inventaire de chaque script présent sur les pages de paiement, le justifier et le vérifier.
- 11.6.1 : détecter les modifications non autorisées des pages de paiement et de leurs en-têtes de sécurité.
Le PCI Security Standards Council a publié des recommandations sur ces règles en 2025. Sur Shopify, les pages de paiement sont contrôlées par Shopify, ce qui est l’une des raisons principales du retrait de checkout.liquid et des balises script du paiement. Nous n’avons trouvé aucune page officielle de Shopify qui attribue ces deux exigences dans toutes les configurations : si vous avez besoin de preuves de conformité, vérifiez-le auprès de Shopify et de votre prestataire de paiement.
8. 3D Secure (3DS2)
Ce qu’il fait : la banque de l’acheteur confirme le paiement, généralement dans son application bancaire mobile.
Ce qu’il bloque : de nombreuses utilisations de numéros de carte volés. Il s’applique aux paiements par carte dans l’Espace économique européen.
Où il s’arrête : les criminels peuvent relayer l’étape de vérification 3DS à travers une fausse boutique, comme Sansec l’a documenté pour le réseau GorgonAgora. L’acheteur approuve un paiement qu’il croit authentique.
9. Défis anti-robots
Ce qu’ils font : un test comme reCAPTCHA ou hCaptcha, rapide pour les vrais acheteurs et coûteux pour les robots.
Ce qu’ils bloquent : les achats automatisés pendant les ventes flash à stock limité, les attaques de test de cartes et certaines formes de scraping.
Où ils s’arrêtent : les tests anti-robots ajoutent de la friction au paiement, et les agents d’achat IA compliquent le tableau : certains visiteurs automatisés sont désormais de véritables clients qui utilisent des assistants IA. La documentation de Shopify sur les agents utilise des requêtes signées et des niveaux de confiance pour les distinguer.
10. Compromis et une règle simple
| Technologie | Protège contre | Ne protège pas contre |
|---|---|---|
| Passkeys | Le phishing des connexions du personnel | Les mauvais collaborateurs invités |
| Jetons signés | Les requêtes falsifiées ou rejouées | Les jetons longue durée qui ont fuité |
| Périmètres | Les dépassements de rôle via l’API | Le comportement des scripts dans le navigateur |
| Bacs à sable | Les pixels et Functions qui lisent le paiement | Les scripts normaux de la vitrine |
| CSP | Les scripts de domaines inconnus | Le mauvais code provenant de domaines autorisés |
| SRI | Les fichiers statiques falsifiés | Le code livré sous forme de données de réglages |
| 3DS | L’usage simple d’une carte volée | L’approbation relayée sur de fausses boutiques |
La règle simple : chaque application que vous installez ajoute du code que vous ne contrôlez pas. Privilégiez les applications aux périmètres étroits, sans accès au paiement, et qui expliquent clairement ce qui s’exécute sur votre vitrine.
11. Questions à poser à tout éditeur d’application
- Quels périmètres demandez-vous, et pourquoi chacun ?
- Votre application exécute-t-elle du code sur ma vitrine ou sur le paiement ? Depuis quelle source est-il chargé ?
- Les champs de réglages de votre application peuvent-ils contenir du JavaScript ou du HTML, et qui peut les modifier ?
- Comment protégez-vous votre propre administration et vos outils internes (2FA, journaux d’accès) ?
- Que deviennent mes données et ma vitrine lorsque je désinstalle l’application ?
Voyez comment Navi+ répond à ces questions, ou lisez ce que Shopify fait déjà pour vous.
Sources
- Shopify Help, Two-step authentication : https://help.shopify.com/en/manual/your-account/account-security/two-step-authentication
- Shopify.dev, Token exchange : https://shopify.dev/docs/apps/build/authentication-authorization/access-tokens/token-exchange
- Shopify.dev, Web pixels : https://shopify.dev/docs/apps/build/marketing-analytics/pixels
- Shopify.dev, Shopify Functions : https://shopify.dev/docs/api/functions
- Shopify.dev, Set up iframe protection : https://shopify.dev/docs/apps/build/security/set-up-iframe-protection
- MDN, Subresource Integrity : https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
- PCI Security Standards Council, Payment Page Security and Preventing E-Skimming : https://blog.pcisecuritystandards.org/new-information-supplement-payment-page-security-and-preventing-e-skimming
- Sansec, GorgonAgora : https://sansec.io/research/gorgonagora-fake-storefront-skimming-network
- cside, HulkApps Shopify checkout hijack : https://cside.com/blog/hulkapps-shopify-checkout-hijack
- Shopify.dev, Agents : https://shopify.dev/docs/agents