TL;DR : la conformité PCI sur Magento
- Magento ne prend pas en charge les exigences 6.4.3 et 11.6.1 à votre place. Chaque script de votre page de paiement doit avoir une entrée d'inventaire, une justification métier et une surveillance continue de son intégrité.
- Les scans ASV répondent à l'exigence 11.3.2. Ils ne détectent pas les menaces JavaScript sur les pages de paiement. Les marchands qui font du scan ASV leur principal contrôle de sécurité passent à côté de ce que PCI DSS 4.0.1 exige réellement pour le risque côté client.
- Le vecteur d'attaque le plus courant contre Magento en 2024 et 2025 est l'exfiltration par WebSocket via des extensions compromises. Elle contourne la CSP, contourne la supervision réseau et n'est visible que pour un outil qui observe directement le runtime du navigateur.
Qu'est-ce que la conformité PCI sur Magento ?
Une boutique Magento n'est pas automatiquement conforme PCI DSS. Magento Commerce Cloud gère une partie des contrôles au niveau de l'infrastructure, mais le marchand reste responsable de la protection de ses pages de paiement contre les attaques côté client. Les exigences 6.4.3 et 11.6.1 de PCI DSS 4.0.1 imposent d'inventorier, d'autoriser et de surveiller l'intégrité de tous les scripts des pages de paiement, des contrôles que Magento ne fournit pas nativement, quelle que soit l'extension de paiement utilisée.
L'idée fausse la plus répandue : les marchands supposent qu'utiliser une extension de paiement certifiée, ou déléguer le traitement du paiement à une page de paiement hébergée, suffit à satisfaire PCI DSS. Cela réduit le périmètre, mais ne l'élimine pas. Toute page Magento qui charge des fonctions de paiement, ou qui entre dans l'environnement des données de porteurs de carte parce qu'elle charge des scripts tiers, relève des exigences 6.4.3 et 11.6.1.
Une page de paiement Magento classique charge des pixels de tracking, des balises analytiques, des outils de test A/B, des scripts d'affiliation, des widgets de chat et des bibliothèques de paiement. Chacun est dans le périmètre. Chacun exige une entrée d'inventaire assortie d'une justification métier. Chacun doit être surveillé pour détecter les modifications d'intégrité entre deux évaluations.
Les exigences PCI DSS que les marchands Magento manquent le plus souvent
Exigence 6.4.3 : inventaire et autorisation des scripts. Tout script chargé sur une page de paiement doit être inventorié. L'inventaire doit documenter la justification métier de chaque script, confirmer qu'il est autorisé et inclure une méthode permettant de vérifier que son intégrité n'a pas changé. Une liste statique dans un tableur ne répond pas à cette exigence : l'inventaire doit refléter l'état réel de la page de paiement, parce que les scripts évoluent.
Exigence 11.6.1 : détection des altérations de la page de paiement. Le marchand doit disposer d'un mécanisme qui détecte les modifications non autorisées des en-têtes HTTP et du contenu de la page de paiement, et qui alerte l'équipe responsable dans un délai défini. Une revue manuelle périodique ne répond pas à cette exigence. Le mécanisme doit être capable de détecter l'apparition d'un nouveau script, la modification d'un script existant ou le changement d'un en-tête HTTP entre deux cycles de revue.
Les deux exigences sont devenues obligatoires le 2025-03-31 et sont désormais évaluées activement. Si votre boutique Magento ne dispose pas d'un outil qui produit des preuves continues pour ces exigences, votre prochaine évaluation PCI DSS est menacée.
Qu'est-ce qu'un Approved Scanning Vendor (ASV) ?
Un Approved Scanning Vendor (ASV) est une société certifiée par le PCI SSC pour réaliser les scans de vulnérabilités externes requis par l'exigence 11.3.2 de PCI DSS. Les scans ASV sondent les composants réseau exposés sur internet à la recherche de vulnérabilités connues. Ils ne détectent ni les menaces JavaScript côté client sur les pages de paiement, ni les scripts tiers non autorisés, ni les anomalies comportementales couvertes par les exigences 6.4.3 et 11.6.1. Réussir un scan ASV ne signifie pas que votre tunnel de paiement Magento est protégé contre les attaques de type Magecart.
Ce que font les scans ASV : sonder vos adresses IP et vos domaines publics à la recherche de CVE connues, de ports ouverts, de services mal configurés et de vulnérabilités réseau. Un rapport ASV propre confirme que le périmètre de vos serveurs ne présente aucune vulnérabilité exploitable connue et détectable depuis l'extérieur.
Ce que les scans ASV ne font pas : analyser le JavaScript exécuté sur vos pages de paiement, détecter les scripts absents lors du scan précédent, vérifier que les scripts tiers n'ont pas été modifiés depuis leur dernière approbation, ni observer les données que les scripts envoient vers des endpoints externes pendant une session de visiteur réelle.
Cet écart n'est pas une critique du scan ASV. C'est la description de ce à quoi l'outil sert. Les contrôles de conformité qui traitent les menaces JavaScript côté client sont le 6.4.3 et le 11.6.1, pas le 11.3.2. Une boutique Magento peut réussir chaque scan ASV trimestriel tout en exécutant un script compromis qui exfiltre des données de porteurs de carte en temps réel.
Le vecteur d'attaque Magento que les scans ASV ne peuvent pas voir
cside suit les TTP actives visant les marchands Magento. Le schéma d'attaque le plus sophistiqué observé en 2024 et 2025 utilise des connexions WebSocket pour l'exfiltration, à la place des requêtes HTTP classiques.
Pourquoi les WebSockets contournent les défenses traditionnelles :
Les attaques Magecart classiques exfiltrent les données via des requêtes HTTP POST vers des domaines contrôlés par l'attaquant. Les directives CSP connect-src peuvent les bloquer si le domaine de l'attaquant n'est pas sur la liste d'autorisation. Les outils de supervision réseau voient le POST sortant et peuvent le signaler.
Les connexions WebSocket en protocole wss:// sont différentes. Beaucoup de configurations CSP ne restreignent pas les origines WebSocket séparément des origines HTTP. Les outils de supervision centrés sur le trafic HTTP peuvent ne pas voir du tout les connexions wss://. L'attaquant maintient un canal bidirectionnel persistant vers le navigateur de la victime, peut modifier les scripts injectés à la volée sans déclencher de nouveau chargement de page, et peut exfiltrer les données de porteurs de carte en continu plutôt que par requêtes POST distinctes.
Le vecteur d'accès : CosmicSting (CVE-2024-34102), divulguée en juin 2024, permettait à des attaquants non authentifiés de lire des fichiers serveur sur les installations Adobe Commerce et Magento, y compris des fichiers de configuration contenant des identifiants de base de données et des clés d'API. Une fois ces identifiants obtenus, les attaquants ont injecté le skimmer WebSocket directement dans les pages de paiement Magento. Le correctif pour CVE-2024-34102 ferme le vecteur d'accès initial. Il ne supprime pas les scripts déjà injectés. Les marchands qui ont appliqué le correctif sans auditer les scripts de leurs pages de paiement à la recherche d'artefacts post-exploitation peuvent encore servir le skimmer.
La seule couche de détection qui attrape cette attaque est celle qui instrumente directement le runtime du navigateur : observer quels scripts s'exécutent dans les sessions de visiteurs réels, quels appels d'API ils effectuent et où ils envoient les données, en temps réel, à chaque session.
Comment cside protège les tunnels de paiement Magento
cside se déploie sous la forme d'un unique snippet JavaScript en first-party sur vos pages de paiement Magento. Il surveille le runtime du navigateur de chaque session de visiteur réel et produit des preuves continues pour les exigences 6.4.3 et 11.6.1.
Pour l'exigence 6.4.3 : cside tient un inventaire vivant de chaque script chargé sur chaque page surveillée, avec le champ de justification métier, le statut d'autorisation et l'empreinte d'intégrité à chaque chargement. Quand un nouveau script apparaît, ou qu'un script existant change, l'inventaire se met à jour et une alerte se déclenche.
Pour l'exigence 11.6.1 : cside détecte les modifications des scripts et des en-têtes HTTP des pages de paiement en temps réel, dans des sessions de visiteurs réels, et génère une piste de preuves horodatée que les QSA acceptent pour cette exigence.
Pour les attaques par WebSocket : parce que cside instrumente directement le runtime JavaScript, il observe les connexions WebSocket ouvertes par les scripts de la page, qu'elles soient visibles ou non dans les journaux de trafic HTTP et qu'elles soient couvertes ou non par la CSP.
Consultez comment se conformer aux exigences PCI 6.4.3 et 11.6.1 pour le détail de la mise en œuvre.
