Test d'intrusion Shopify : Liquid SSTI, Applications Tierces et Logique Métier
Shopify est la plateforme e-commerce SaaS leader mondial avec plus de 4 millions de boutiques actives. Son modèle d'extensibilité — applications tierces via l'App Store Shopify, thèmes personnalisables en Liquid, webhooks et API REST/GraphQL — crée une surface d'attaque distincte des applications web traditionnelles. Les risques ne portent pas sur l'infrastructure Shopify elle-même (gérée par Shopify Inc.), mais sur votre configuration de boutique, vos applications installées, votre code Liquid personnalisé et la logique de vos processus commerciaux. Un seul token OAuth d'application malveillante ou une injection de template Liquid peut conduire à l'exfiltration complète de votre catalogue, de vos données clients et de vos informations de commandes.
Pourquoi les boutiques Shopify nécessitent des tests de sécurité spécialisés
Le modèle de responsabilité partagée de Shopify (Shopify sécurise l'infrastructure, le marchand est responsable de sa configuration et de ses applications) signifie que de nombreux vecteurs d'attaque relèvent entièrement de la responsabilité du marchand. Les applications Shopify demandent des scopes OAuth souvent très larges (lire toutes les commandes, modifier les produits, accéder aux données clients) ; une application compromise ou malveillante avec ces permissions peut exfiltrer l'intégralité du catalogue et des données clients. Le langage de template Liquid, bien que conçu avec des restrictions, peut présenter des risques d'injection dans les implémentations personnalisées. Les processus de paiement et de remise concentrent souvent des vulnérabilités de logique métier permettant la manipulation des prix ou l'obtention de remises non autorisées.
- CVE-2022-21664 (injection SQL WordPress/WooCommerce sur installations multisite) : bien que techniquement une CVE WordPress, elle illustre la classe d'attaques de contamination croisée dans les environnements multi-boutiques ou les configurations WordPress + WooCommerce + Shopify hybrides. Les marchands utilisant des intégrations entre Shopify et des installations WordPress/WooCommerce restent exposés à ce vecteur dans leur stack combiné.
- Server-Side Template Injection (SSTI) dans le langage Liquid : Shopify Liquid est un moteur de templates avec des restrictions de sécurité, mais les thèmes personnalisés acceptant des entrées utilisateur et les insérant dans des blocks Liquid sans validation adéquate peuvent être vulnérables à des formes d'injection de template. L'exploitation dépend de la version et du contexte, mais peut conduire à la divulgation d'informations de configuration de la boutique.
- Abus des applications Shopify OAuth et permissions excessives : les applications Shopify demandent des scopes OAuth lors de l'installation. Les applications avec des scopes larges (read_all_orders, write_products, read_customers) constituent une cible de premier choix si elles sont compromises ou si elles envoient des données vers des backends tiers non sécurisés. Un inventaire et un audit des permissions des applications installées est essentiel.
- Manipulation de la logique de prix et de remises : les remises Shopify, codes promotionnels et règles de prix automatiques peuvent parfois être combinés ou manipulés pour obtenir des réductions non intentionnelles. Les APIs de panier et de checkout Shopify (Storefront API) peuvent être exploitées pour tester des combinaisons de remises extrêmes non prévues par la configuration.
- Exposition des webhooks Shopify sans validation de signature : les webhooks Shopify transmettent des données sensibles (nouvelles commandes, mises à jour clients) vers des endpoints externes. Sans validation systématique de la signature HMAC-SHA256 incluse dans l'en-tête X-Shopify-Hmac-Sha256, un attaquant peut envoyer de faux événements webhook pour déclencher des actions automatisées frauduleuses.
- Sécurité de l'API Storefront et de l'API Admin : le token public Storefront API est conçu pour une utilisation côté client, mais des scopes incorrectement configurés peuvent exposer des données qui devraient rester privées. Le token Admin API doit rester strictement côté serveur ; son exposition dans le code JavaScript frontend est une faute critique.
- Données clients et conformité RGPD : Shopify stocke des données personnelles de clients (nom, adresse, email, historique d'achat) ; les intégrations avec des outils marketing tiers, les pixels de tracking et les applications d'analyse doivent être auditées pour la conformité RGPD et les transferts de données non autorisés.
Ce qui est examiné lors d'un test d'intrusion Shopify
- Audit des applications Shopify installées et de leurs permissions OAuth : inventaire complet de toutes les applications actives et inactives avec leurs scopes OAuth, identification des applications aux permissions excessives, des applications abandonnées ou des éditeurs suspects, vérification des politiques de confidentialité et des destinations des données.
- Tests d'injection dans les thèmes Liquid personnalisés : analyse du code Liquid pour les points d'entrée utilisateur insérés dans des contexts de template ; test SSTI sur les champs de recherche, les métafields personnalisés et les blocks de section acceptant des entrées non filtrées.
- Validation des signatures de webhooks : vérification que tous les endpoints recevant des webhooks Shopify valident systématiquement la signature HMAC-SHA256 ; test d'envoi de webhooks falsifiés pour confirmer le rejet des requêtes non authentifiées.
- Sécurité de l'API Storefront : vérification que le token Storefront API public n'expose pas de données privées de clients, de commandes ou de stocks non publics ; test des mutations GraphQL pour les accès non autorisés.
- Tests de manipulation de la logique de remises et de prix : tests de combinaison de multiples codes promo, remises automatiques et remises manuelles pour identifier des réductions non intentionnelles ; test de manipulation des paramètres de checkout pour modifier les prix des articles.
- Sécurité des pages de compte client et IDOR : test d'accès aux commandes, adresses et données de profil d'autres clients via manipulation d'identifiants dans les URLs /account/orders/{id} et les appels API Storefront.
- Exposition des tokens API et secrets dans le code frontend : recherche de tokens Admin API, secrets d'application ou clés privées dans les fichiers JavaScript du thème, les appels AJAX et les réponses du Storefront API.
- Intégrations tierces et flux de données : audit des pixels de tracking (Meta Pixel, Google Analytics), des applications marketing et des intégrations ERP/CRM pour les transferts de données non chiffrés ou non autorisés ; vérification RGPD pour les transferts hors UE.
- Sécurité du processus de checkout Shopify : test de manipulation des paramètres de la page de checkout pour modifier les montants, les frais de livraison ou les taxes ; vérification des mécanismes de prévention de la fraude configurés.
- Configuration des en-têtes de sécurité et politique CSP : vérification des en-têtes HTTP de sécurité sur la boutique (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security) pour les thèmes personnalisés injectant du JavaScript tiers.
Exemple de finding
Token API Admin Shopify exposé dans le JavaScript frontend du thème
L'examen du code JavaScript du thème Liquid personnalisé a révélé la présence du token API Admin Shopify (format shpat_xxxx) directement dans un fichier assets/theme.js. Ce token possédait les scopes : read_products, write_products, read_orders, read_customers. Un attaquant accédant à ce fichier JavaScript — accessible publiquement sans authentification — pouvait utiliser ce token pour exfiltrer l'intégralité du catalogue (prices, stock, metadata), toutes les commandes passées (données clients, adresses de livraison, montants) et les informations de contact des 12 847 clients de la boutique via l'API Admin REST.
Correction : Révoquer immédiatement le token Admin API exposé dans le tableau de bord Shopify Partners. Déplacer toutes les interactions avec l'API Admin vers un backend serveur (Shopify Function, Edge Function, ou serveur dédié) — le token Admin ne doit jamais apparaître dans le code exécuté côté navigateur. Pour les opérations côté client légitimes, utiliser uniquement le Storefront API avec un token public aux scopes minimaux. Auditer les logs d'accès Shopify pour déterminer si le token a été utilisé par des tiers depuis son exposition.
Référence : OWASP A02:2021 Cryptographic Failures · OWASP A01:2021 Broken Access Control · Shopify API Security Best Practices · CWE-312 Cleartext Storage of Sensitive Information
Pentest Shopify : comparaison des options
| — | Scan gratuit | Matproof Sentinel | Consultance classique |
|---|---|---|---|
| Moteur de scan automatisé | ✓ (aperçu 3 min) | ✓ Scan complet | ✗ Manuel uniquement |
| Couverture OWASP Top 10 | Partielle | ✓ Complète | ✓ Complète |
| Preuve d'exploitation | ✗ | ✓ Par finding | ✓ Par finding |
| Mapping réglementaire (DORA/NIS2/ISO 27001) | ✗ | ✓ Automatisé | ✓ Manuel |
| Rapport PDF prêt pour l'audit | ✗ | ✓ Instantané | ✓ Livraison 2–4 semaines |
| Scans continus / récurrents | ✗ | ✓ Par déploiement | ✗ Engagement annuel |
| Délai avant premier résultat | ~3 min | ~30 min scan complet | 2–4 semaines |
| Prix | €0 | À partir de €149 | €8 000–€25 000 |
| Revue de code source (SAST) | ✗ | ✓ Plan Growth | ✓ Périmètre défini |
| Tests API (REST/GraphQL) | ✗ | ✓ Automatisé | ✓ Manuel |
Offres de pentest Shopify
- 1 scan pentest complet
- Résultats priorisés par IA avec CVSS 3.1
- Proof-of-exploit pour chaque finding
- Rapport PDF (prêt pour l'audit)
- Mapping réglementaire (DORA, NIS2, ISO 27001)
- Scans illimités (jusqu'à 3 domaines)
- Surveillance continue
- Intégration CI/CD (GitHub, GitLab)
- Tous les mappings réglementaires
- Support prioritaire
- Scans + domaines illimités
- Tests authentifiés / White-Box
- Tests d'API et d'infrastructure cloud
- Account manager sécurité dédié
- SLA réponse 24h
Questions fréquentes sur le test d'intrusion Shopify
Shopify étant une plateforme SaaS, quelle est la responsabilité du marchand en matière de sécurité ?
Shopify applique un modèle de responsabilité partagée. Shopify Inc. est responsable de la sécurité de l'infrastructure (serveurs, réseau, stockage, core de la plateforme). Le marchand est responsable de : la configuration de sa boutique, les applications tierces installées et leurs permissions, le code personnalisé des thèmes Liquid, la gestion des tokens API, la configuration des webhooks, et les intégrations avec des systèmes externes. Les failles les plus fréquentes dans les boutiques Shopify se situent entièrement dans le périmètre de responsabilité du marchand.
Le langage Liquid est-il vraiment vulnérable aux injections SSTI et dans quels cas ?
Liquid est conçu avec des restrictions de sécurité qui limitent l'accès au système de fichiers et l'exécution de code arbitraire. Cependant, des risques existent dans les cas suivants : (1) thèmes personnalisés utilisant des filtres Liquid non sanitisés sur des entrées utilisateur, pouvant conduire à une divulgation d'informations via la manipulation de variables de scope global ; (2) certains objets Liquid exposent des informations de configuration accessibles dans des contextes non prévus ; (3) des CMS headless ou intégrations tierces utilisant un rendu Liquid côté serveur personnalisé avec une sandbox moins stricte. L'évaluation nécessite une analyse du code Liquid spécifique à votre thème.
Comment auditer les applications Shopify installées pour détecter les risques de sécurité ?
Processus d'audit recommandé : (1) dans l'admin Shopify, aller dans Paramètres > Applications et canaux de vente — noter toutes les applications actives et inactives ; (2) pour chaque application, examiner les scopes OAuth demandés lors de l'installation (visibles dans les notifications d'autorisation) ; (3) vérifier sur Shopify App Store si l'application est maintenue activement (date de dernière mise à jour) ; (4) pour les applications avec read_orders ou read_customers, demander la politique de confidentialité et la liste des sous-processeurs ; (5) désinstaller les applications non utilisées — même inactives, des tokens OAuth peuvent rester valides. Matproof automatise cet inventaire et score chaque application par niveau de risque.
Comment valider correctement les webhooks Shopify pour éviter la falsification ?
La validation HMAC-SHA256 est obligatoire pour tous les webhooks Shopify. Processus : (1) récupérer la valeur de l'en-tête X-Shopify-Hmac-Sha256 de la requête entrante ; (2) calculer HMAC-SHA256 du body brut de la requête avec votre clé secrète de webhook (affichée dans les paramètres webhook Shopify) ; (3) comparer les deux valeurs en temps constant (utiliser crypto.timingSafeEqual en Node.js ou hmac.compare_digest en Python pour éviter les attaques timing). Rejeter toute requête dont la signature ne correspond pas. Cette vérification doit être implémentée avant tout traitement du payload.
Quels sont les risques liés aux intégrations Shopify + ERP ou Shopify + PIM ?
Les intégrations Shopify avec des systèmes ERP (SAP, Netsuite) ou PIM (Akeneo, Contentful) introduisent des risques supplémentaires : tokens d'API bidirectionnels avec des permissions larges stockés dans les deux systèmes, synchronisation de données sensibles (stocks, prix, données clients) via des APIs potentiellement non chiffrées ou avec une authentification faible, webhooks ou tâches cron tournant avec des clés jamais renouvelées, et surfaces d'attaque élargies si l'ERP est hébergé on-premise. Un pentest d'intégration doit couvrir les deux extremités de la connexion et le canal de transmission.
Shopify est-il conforme au PCI DSS et que doit faire le marchand ?
Shopify Payments (et Shopify en tant que plateforme) est certifié PCI DSS Level 1 pour les flux de paiement gérés nativement. Cela couvre le stockage et le traitement des données de carte sur l'infrastructure Shopify. La responsabilité du marchand concerne : les intégrations de paiement tierces (Stripe, Adyen configurés manuellement) qui peuvent sortir du périmètre de la certification Shopify, le stockage de données de commande dans des systèmes externes non certifiés PCI, et les applications marketing accédant aux données de transaction. Un pentest PCI DSS spécifique peut être requis si votre boutique utilise des intégrations de paiement custom.
Comment sécuriser les accès administrateur à la boutique Shopify ?
Mesures essentielles pour la sécurité de l'administration Shopify : (1) activer l'authentification à deux facteurs (2FA) pour tous les comptes staff ayant accès à l'admin — obligatoire pour les comptes Owner ; (2) utiliser les permissions granulaires par staff member (éviter de donner l'accès 'Owner' à tous les collaborateurs) ; (3) activer les restrictions IP pour l'accès admin si vous opérez depuis des IPs fixes ; (4) auditer régulièrement la liste des collaborateurs et retirer les accès des anciens employés immédiatement ; (5) pour les agences externalisées, utiliser des accès collaborateur Shopify Partners avec des permissions minimales et une date d'expiration.
Qu'est-ce qui est inclus dans le rapport de pentest Shopify Matproof ?
Le rapport Matproof Sentinel pour Shopify inclut : inventaire complet des applications avec scoring de risque OAuth, résultats des tests d'injection Liquid avec preuves (requêtes/réponses), tests de logique de remise avec les combinaisons testées et les résultats, vérification de la validation des webhooks, exposition des tokens et secrets, conformité des en-têtes HTTP, recommandations de remédiation priorisées par criticité (CVSS), et un résumé exécutif adapté à la présentation à votre direction ou à vos clients B2B qui exigent des preuves de diligence raisonnable en sécurité.
Approfondir — articles de blog associés
Démarrez votre test d'intrusion Shopify maintenant
Vérifiez en quelques minutes si vos applications Shopify ont des permissions excessives, si votre thème Liquid est vulnérable ou si votre logique de remises peut être manipulée. Rapport audit-ready en français, aucune installation requise.
Démarrer le pentest Shopify