Meilleur logiciel de protection contre Magecart 2026 : intégrité des scripts sur les pages de paiement

TL;DR : détection du skimmer dès la première session affectée

• Le CSP est un portier : Une Content Security Policy est un portier, pas un garde du corps. Elle empêche le chargement de nouveaux scripts mais laisse passer une balise approuvée dans laquelle un fournisseur a glissé un skimmer pendant la nuit.
• Référence de chaque script de paiement : La protection Magecart la plus solide établit une référence comportementale pour chaque script de la page de paiement et alerte, dans la même session où il change, lorsqu'un script autorisé commence à toucher des champs de formulaire qu'il n'avait jamais touchés. C'est la détection d'altération à l'exécution qu'exige PCI DSS 4.0.1 Exigence 11.6.1, et qu'une CSP ne peut pas fournir.
• La checklist de l'acheteur : Qu'un outil comble réellement la faille se résume à une courte liste de contrôle, détaillée dans les critères d'achat ci-dessous : surveillance en temps réel dans de vraies sessions utilisateurs, détection des changements de comportement dans les scripts déjà approuvés, archivage des payloads désobfusqués pour l'analyse forensique, et preuves validées par un QSA pour les Exigences 6.4.3 et 11.6.1. Notez chaque option du tableau comparatif au regard de cette liste.

Peu de temps ? Découvrez le blocage in-browser des Magecart et skimmers de cside. Elle couvre tout ce qui suit en un seul déploiement.

Le meilleur logiciel de protection contre Magecart surveille en temps réel chaque script de votre page de paiement et déclenche une alerte à l'instant où un script, propriétaire ou tiers, lit un champ de paiement ou envoie des données vers un endpoint qu'il ne devrait pas. Une Content Security Policy empêche le chargement de scripts inconnus, mais elle ne peut pas détecter un changement de comportement à l'intérieur d'un script que vous avez déjà approuvé, c'est pourquoi PCI DSS 4.0.1 exige désormais une surveillance de l'intégrité des scripts à l'exécution sur les pages de paiement.

Les attaques Magecart compromettent la chaîne d'approvisionnement JavaScript des pages de paiement. Un attaquant injecte du code de skimming dans un script tiers que votre site charge déjà et auquel il fait confiance (une balise d'analytique, un widget de chat, un pixel marketing), et ce script commence à collecter les données de carte de paiement depuis les champs du formulaire de paiement sans changement visible sur la page. Un paiement moyen charge des dizaines de scripts tiers, et chacun est un point d'injection potentiel.

Le PCI Security Standards Council a concrétisé ce risque dans PCI DSS 4.0.1. L'Exigence 6.4.3 impose que tous les scripts des pages de paiement soient inventoriés et autorisés. L'Exigence 11.6.1 impose la détection d'altération, c'est-à-dire des alertes automatiques lorsqu'un script d'une page de paiement change de comportement. Les deux exigences sont devenues obligatoires le 2025-03-31.

Pourquoi une Content Security Policy est nécessaire mais pas suffisante

Une Content Security Policy (CSP) est une liste d'autorisation appliquée par le navigateur qui bloque le chargement des scripts sauf si leur source est explicitement autorisée. Pour Magecart, une CSP empêche un attaquant d'injecter un nouveau script étranger sur une page de paiement.

Elle n'empêche pas un attaquant de compromettre un script déjà présent sur la liste d'autorisation. Si un attaquant accède au CDN ou au dépôt de code d'un fournisseur tiers que votre CSP autorise déjà, il peut modifier le script de ce fournisseur pour y inclure du code de skimming. La CSP voit le script se charger depuis la même source autorisée et l'autorise, donc le skimmer s'exécute à l'intérieur d'un script approuvé.

L'Exigence 11.6.1 existe parce que le PCI SSC a reconnu cette faille. Elle vous demande de détecter quand un script approuvé change ce qu'il fait, ce qui nécessite une surveillance du comportement à l'exécution. Une CSP ne peut pas fournir cela.

cside : détection de Magecart en temps réel

La protection Magecart de cside surveille en temps réel chaque script chargé sur la page de paiement. Elle établit une référence comportementale pour chaque script approuvé (à quels éléments du DOM il accède, quelles destinations réseau il appelle, quelles données il lit) et alerte dès qu'un script s'écarte de cette référence.

Lorsqu'un script tiers compromis commence à accéder à des champs du formulaire de paiement qu'il n'avait jamais touchés, cside détecte le changement dans la même session où il se produit. L'alerte identifie le script précis, le changement de comportement précis et l'horodatage, afin que vous disposiez de preuves utilisables lors d'une évaluation PCI.

cside tient également l'inventaire de scripts exigé par l'Exigence 6.4.3 : une liste complète et continuellement mise à jour de chaque script présent sur la page de paiement, avec le statut d'autorisation de chacun. Comme l'inventaire et la détection d'altération sont livrés dans un seul déploiement validé, un seul outil satisfait les deux exigences. cside est validé par VikingCloud pour PCI DSS 4.0.1 Exigences 6.4.3 et 11.6.1.

Pour situer le contexte, le skimming des pages de paiement reste un moteur principal de la compromission des données de carte par le web pour les marchands. Détecter l'injection Magecart dès la première session affectée est ce qui empêche un seul fournisseur compromis de devenir un incident massif de données de carte.

Reflectiz

Reflectiz est une plateforme de sécurité de sites web qui surveille les scripts tiers pour repérer les changements de comportement et les risques. Son modèle de détection repose sur des scans distants périodiques depuis une infrastructure de crawler : un navigateur exécuté depuis l'IP d'un fournisseur cloud visite vos pages selon un calendrier et rapporte ce qu'il voit.

Pour Magecart, ce modèle de scan programmé est la limite centrale. Un navigateur depuis une IP cloud connue n'équivaut pas à un script s'exécutant dans le DOM réel d'une vraie session utilisateur, et les skimmers côté client s'adaptent régulièrement au visiteur. Un attaquant qui identifie le scanner peut lui servir une page propre pendant que les vrais acheteurs reçoivent la version malveillante, si bien qu'un scanner peut créer un faux sentiment de couverture entre les scans. Un scanner ponctuel comme Reflectiz voit encore moins qu'un agent en page échantillonné, car il ne s'exécute dans aucune vraie session utilisateur, seulement ce qui se charge pendant son crawl programmé. Sur le plan de l'assurance, d'après les documents publics examinés le 2026-05-20, Reflectiz ne publiait pas d'approbation QSA équivalente, de PCI DSS SAQ D ni de certification SOC 2 Type II, et ne publie aucune page de statut publique ni SLA de disponibilité ; son tarif n'est pas public non plus.

cside s'exécute dans 100% des sessions d'utilisateurs réels sans échantillonnage et télécharge chaque script vers sa propre infrastructure pour une analyse côté serveur, de sorte qu'un acteur malveillant ne peut pas lui servir un script propre comme il peut le faire à un crawler programmé, et chaque payload est archivé comme preuve. cside offre aussi une couverture basée sur un scanner via son Scan Method pour les cas où un déploiement de script n'est pas possible, mais il ne fait pas du scan tout le modèle de sécurité, et il est validé par QSA par VikingCloud pour PCI DSS 4.0.1 Exigences 6.4.3 et 11.6.1.

Source Defense

Source Defense se spécialise dans la sécurité de sites web côté client et cible les marchands d'entreprise. Il propose deux méthodes pour les scripts des pages de paiement : Source Defense Detect, un crawler qui imite un utilisateur visitant la page pour récupérer les scripts tiers qui se chargent, et Source Defense Protect, un agent JavaScript qui construit un sandbox côté client pour isoler les scripts et limiter ce à quoi ils peuvent accéder.

Pour Magecart, les deux méthodes ont des failles qu'un skimmer peut exploiter. Le crawler n'est qu'une combinaison spécifique de lieu, d'appareil et de moment, il ne capture donc pas le payload exact que reçoit un vrai visiteur, et un attaquant peut repérer l'infrastructure cloud et lui servir un script propre. L'agent JavaScript est basé sur des déclencheurs, donc tout ce qui ne déclenche pas est considéré comme bon, et comme les déclencheurs sont définis dans le navigateur, un acteur malveillant peut les étudier et concevoir un skimmer qui les évite. Le sandbox ajoute jusqu'à 100ms de latence, et comme l'agent s'exécute dans le même environnement de navigateur que l'attaquant, un script déjà en cours d'exécution peut redéfinir des fonctions centrales comme fetch et couper l'alerte avant qu'elle ne quitte la page. Le plus important pour l'analyse forensique du skimming : Source Defense ne peut pas vous montrer le contenu des scripts, il est donc difficile de prouver ce qu'un script compromis a réellement fait.

cside analyse chaque script côté serveur, sur une infrastructure que l'attaquant ne peut ni voir ni manipuler, si bien que la détection ne peut pas être identifiée et désactivée comme peut l'être un agent côté navigateur. Lorsqu'une détection se déclenche, cside conserve le payload malveillant exact dans une archive immuable, offrant à votre équipe de réponse aux incidents et à un QSA le véritable code d'attaque plutôt qu'une alerte comportementale. Le moteur de cside apprend aussi ce que chaque script est censé faire et signale automatiquement les écarts, au lieu d'exiger les règles d'autorisation par script qu'un modèle de sandbox doit maintenir à jour à mesure que votre paiement évolue.

Jscrambler

Jscrambler a commencé dans l'obfuscation de JavaScript et a ajouté plus tard un produit d'intégrité de pages web. Sa force principale est de protéger le JavaScript propriétaire, en transformant le code propriétaire pour le rendre plus difficile à rétroconcevoir, avec des « verrous de code » qui restreignent où et quand le code s'exécute. Pour la détection des menaces côté client, il utilise une approche basée sur des pièges : il injecte des objets leurres et du code de surveillance dans vos pages et attend qu'un script malveillant interagisse avec ces pièges.

Pour Magecart, la détection basée sur des pièges a la même faiblesse centrale que tout modèle uniquement dans le navigateur : elle ne sait pas ce qu'elle n'a pas attrapé. Un skimmer qui évite les objets leurres ou bloque les endpoints de callback passe inaperçu, et comme le code de surveillance s'exécute dans le navigateur, un attaquant sophistiqué peut le trouver et le contourner. Jscrambler ne suit pas du tout le contenu des scripts, si bien qu'après une attaque échantillonnée ou conditionnelle il ne reste souvent aucun payload malveillant à analyser, ce qui complique l'analyse forensique et les preuves PCI. L'obfuscation ne comble pas non plus la faille, puisque le navigateur exécute toujours des appels d'API observables et que la désobfuscation assistée par LLM lit de mieux en mieux l'intention.

cside a été conçu pour la sécurité côté client et pour PCI DSS 6.4.3 et 11.6.1 dès le départ. Il surveille le comportement des scripts dans de vraies sessions utilisateurs sans échantillonnage, télécharge chaque script pour une analyse approfondie sur sa propre infrastructure (avec des LLM qu'il exécute lui-même, aucune donnée de script ne part donc vers un fournisseur d'IA tiers) et archive le code d'attaque brut pour examen par un QSA. Dans la catégorie indépendante Sécurité Côté Client des Globee Cybersecurity Awards 2026, cside a remporté l'Or (Meilleur de la Catégorie) et Jscrambler a remporté l'Argent.

DomDog

DomDog est conçu spécifiquement pour les exigences 6.4.3 et 11.6.1 de PCI DSS 4.0.1, avec des informations produit entièrement publiques et un tarif qui commence à $999 par an, comparable à cside. L'installation consiste en un unique script ajouté à la balise du header. Il fonctionne comme un agent JavaScript qui collecte des données, affiche les scripts dans un tableau de bord et demande à l'utilisateur de les examiner et de les ajouter à une liste d'autorisation ou de blocage, soutenu par une Content Security Policy secondaire.

Pour Magecart en particulier, cette conception agent plus CSP laisse une véritable fenêtre de skimming. Comme DomDog ne se situe pas dans le flux de livraison des scripts, un script XSS stocké qui devient malveillant peut s'activer sans être attrapé, et sa CSP fait confiance à des sources préapprouvées plutôt qu'à leur contenu, si bien qu'un échange de contenu de même origine, exactement le schéma Polyfill où polyfill[.]io restait le domaine mais le payload changeait, passe à travers. DomDog surveille les changements de comportement mais n'analyse ni n'archive les payloads, la détection se produit donc après la livraison et il n'y a pas de code d'attaque à remettre à un auditeur. cside n'a pas pu trouver de certification SOC 2 ou PCI DSS publiée pour DomDog.

cside effectue l'analyse des payloads sur sa propre infrastructure, en téléchargeant les scripts côté serveur et en identifiant l'intention malveillante au niveau du code, ce qui attrape les skimmers ciblés qui ne s'activent que dans des conditions spécifiques comme certaines zones géographiques, fenêtres de temps ou types d'appareil. Il conserve des archives immuables de chaque payload de script avec l'historique complet des versions, si bien qu'un audit obtient le véritable code d'attaque et une chronologie complète plutôt qu'un journal de changements de comportement, et sa couverture s'étend au-delà des normes des cartes de paiement à HIPAA, GDPR et CPRA.

Comment choisir un logiciel de protection contre Magecart

Ignorez les noms des fournisseurs et notez chaque option du tableau comparatif au regard de ces critères. Magecart est une menace à l'exécution et intra-session, un outil doit donc tous les remplir, pas la plupart, pour combler réellement la faille :

• Surveillance des scripts en temps réel dans 100% des sessions d'utilisateurs réels, sans échantillonnage. Un scanner distant périodique ou un crawler depuis une infrastructure cloud peut recevoir un script propre pendant que les vrais acheteurs sont skimmés. La couverture doit se situer dans le vrai trafic utilisateur, pas dans une visite programmée.
• Détecte les changements de comportement dans les scripts déjà approuvés. Le vecteur Magecart le plus courant est un script compromis qui figurait déjà sur votre liste d'autorisation. Bloquer les nouveaux scripts ne suffit pas ; l'outil doit signaler quand un script autorisé commence à lire des champs de formulaire ou à appeler des endpoints qu'il n'avait jamais touchés.
• Une détection que l'attaquant ne peut ni voir ni désactiver. Si la surveillance s'exécute entièrement dans le navigateur, un acteur malveillant peut étudier les déclencheurs et les contourner, ou intercepter l'alerte avant qu'elle ne quitte la page. L'analyse sur l'infrastructure propre du fournisseur supprime cette surface d'attaque.
• Archivage des payloads désobfusqués pour l'analyse forensique. Les alertes comportementales seules ne prouvent pas ce qui s'est passé. Vous voulez une archive immuable du véritable code d'attaque (désobfusqué), car les skimmers sont souvent échantillonnés ou conditionnels et ne laissent sinon rien derrière eux.
• Des preuves validées par un QSA pour PCI DSS 6.4.3 et 11.6.1. Les deux exigences sont devenues obligatoires le 2025-03-31. Les rapports autodéclarés peuvent encore nécessiter une validation indépendante au moment de l'évaluation, exigez donc une validation QSA indépendante, pas une case cochée.
• Un niveau gratuit pour le prouver avant de signer. Vous devriez pouvoir vérifier la détection sur vos propres pages de paiement avant d'engager un budget.

Notez chaque outil honnêtement au regard de cette liste. Une seule ligne du tableau ci-dessus remplit tous les critères.

Content Security Policy seule

Une CSP est un contrôle gratuit et natif du navigateur, et devrait être déployée sur chaque page de paiement comme base. Elle ne remplace pas un logiciel de surveillance à l'exécution.

Une CSP bien configurée avec des nonces ou des hachages sur les scripts inline prévient la plupart des injections Magecart opportunistes. Elle ne surveille pas le comportement à l'exécution des scripts approuvés, elle n'alerte pas quand un script approuvé change ce qu'il fait, et elle ne produit pas la piste d'audit exigée par PCI DSS 4.0.1 Exigence 11.6.1. Traitez une CSP comme le point de départ, pas comme la solution complète.

Essayez cside avant d'acheter. cside propose un plan gratuit : vous pouvez vous inscrire, le déployer et explorer la plateforme par vous-même, sans appel commercial ni processus d'achat. Et notre équipe de support est à portée de message dès que vous avez besoin d'aide.

Pour aller plus loin

• cside PCI Shield
• Cas d'usage attaque Magecart
• Aperçu de la conformité PCI DSS