Le meilleur outil de détection Magecart pour PCI DSS est celui dont la sortie sera acceptée comme preuve par un QSA. Une détection qui ne fait que bloquer ou seulement alerter ne suffit pas. Les exigences 6.4.3 et 11.6.1 vous demandent de prouver quatre choses dans le temps : que vous connaissez chaque script de votre page de paiement, que chacun est autorisé, que vous êtes alerté quand l'un change sans approbation, et que vous pouvez montrer l'historique.
Cela recadre la décision d'achat. Cherchez un système d'enregistrement qui transforme un événement de la couche navigateur en une entrée d'inventaire, une décision d'autorisation, une alerte d'altération et un journal de changements conservé, pas seulement l'alarme de skimmer la plus bruyante. La plupart du marketing « détection Magecart » parle de l'attrape. L'audit demande la paperasse derrière l'attrape.
Cet article évalue les outils de détection à travers cette lentille de preuve PCI. Il ne classe pas des vendors nommés et ne cite pas de spécifications. Il vous indique quel artefact de preuve chaque catégorie de capacité produit, où chaque catégorie laisse un trou, et quoi exiger dans un essai. PCI DSS 4.0.1 a rendu 6.4.3 et 11.6.1 obligatoires le 2025-03-31, donc la question de preuve est vivante maintenant, pas au prochain renouvellement. Si votre stack couvre déjà les menaces connues comme mauvaises, le trou est généralement la documentation, c'est pourquoi la prévention Magecart et la preuve PCI sont désormais le même travail.
Quelle preuve un QSA veut-il réellement de la détection Magecart ?
Mappez le texte de l'exigence à l'artefact que votre outil doit produire. Ce sont les choses qu'un évaluateur ouvre pendant une revue 6.4.3/11.6.1.
| Artefact de preuve PCI | Exigence à laquelle il répond | Ce que « bien » ressemble |
|---|---|---|
| Inventaire des scripts | 6.4.3 (savoir ce qui tourne) | Chaque script sur la page de paiement, y compris les scripts injectés dynamiquement et les scripts CDN tiers, capturés comme le navigateur les voit |
| Enregistrement d'autorisation | 6.4.3 (justifier chaque script) | Une justification et un état d'approbation par script, avec qui a décidé et quand |
| Alerte d'intégrité / d'altération | 11.6.1 (détecter le changement) | Une alerte sur changement non autorisé du contenu des scripts et des en-têtes HTTP de la page de paiement, avec un diff |
| Historique des changements | 6.4.3 + 11.6.1 (prouver dans le temps) | Un journal durable et horodaté de chaque ajout, modification et retrait de script, plus le traitement de chaque alerte |
Le piège est de traiter la détection Magecart comme une fonctionnalité de sécurité et PCI comme une case séparée. C'est le même contrôle. Si l'outil attrape un skimmer mais ne peut pas montrer à l'évaluateur l'entrée d'inventaire à laquelle ce script appartenait, l'état d'autorisation qu'il a violé, et l'enregistrement daté de l'alerte et de sa clôture, vous avez attrapé l'attaque et vous échouez quand même à l'audit sur la documentation.
Pourquoi une comparaison par signatures de malware rate la question PCI
La plupart des listes « meilleurs outils de détection » comparent sur la couverture de menaces : signatures connues comme mauvaises, blocklists, feeds de domaines malveillants. Cela compte pour le blocage. Cela ne satisfait pas 6.4.3 ni 11.6.1.
Le Magecart de chaîne d'approvisionnement arrive via un script en lequel vous avez déjà confiance. Le CDN du vendor sert une nouvelle version, l'origine est sur votre allowlist, et le hash change pour une raison qui a l'air légitime. Un moteur de signatures ne voit rien parce que le payload est nouveau et la source est permise. Le contrôle PCI est conçu exactement pour cela : 6.4.3 vous oblige à inventorier et autoriser ce script à l'avance, et 11.6.1 vous oblige à alerter quand son contenu change sans approbation. La preuve, pas la signature, est ce qui prouve que vous auriez attrapé la substitution.
Évaluez donc la détection sur sa production d'enregistrement d'autorisation-et-changement, pas seulement sur sa reconnaissance des skimmers connus d'aujourd'hui.
Comment évaluer la détection Magecart par catégorie de capacité
Les outils de détection tombent dans quelques catégories architecturales. Chacune produit une preuve différente et laisse un trou différent. Notez-les sur ce qu'ils remettent à l'évaluateur.
| Catégorie de capacité | Inventaire | Enregistrement d'autorisation | Alerte d'altération (contenu + en-têtes) | Historique des changements | Lacune principale de preuve |
|---|---|---|---|---|---|
| Scanner externe (crawler depuis des IPs cloud) | Partiel, ne voit que ce que son crawler charge | Généralement manuel, greffé par-dessus | Périodique, peut manquer entre les scans | À base de snapshots | Manque les scripts par session, géo-ciblés et post-interaction |
| CSP + SRI (politique appliquée par le navigateur) | Non, il contraint plutôt qu'il n'énumère | Non | Politique d'en-tête seulement ; SRI casse sur les scripts dynamiques | Rapports de violation, pas un journal d'audit | Génère du contrôle, pas la paperasse d'inventaire ou d'autorisation |
| Visibilité scripts réseau/WAF | Partiel, ce qui traverse l'edge | Non | En-têtes et blocage des connus malveillants | Logs d'edge, pas d'historique par script | Pas d'état d'autorisation par script pour le QSA |
| Surveillance runtime navigateur (agent dans la page) | Oui, capture les scripts comme le navigateur les exécute | Oui, quand la plateforme modélise l'état d'approbation | Oui, changement de contenu et d'en-tête, avec diff | Oui, journal durable, horodaté par script | Exige un tag sur la page de paiement |
Lisez le tableau comme une checklist de preuve, pas comme un concours de popularité. Un scanner est rapide à déployer et utile pour une baseline, mais un skimmer qui ne s'active que pour de vrais acheteurs dans un seul pays peut servir une page propre à l'IP du crawler. CSP et SRI sont de vrais contrôles que le PCI SSC nomme comme mécanismes valides, mais ils produisent de la politique et des rapports de violation, pas l'inventaire des scripts et les enregistrements d'autorisation qu'exige 6.4.3, et les hashes de SRI cassent sur les scripts dynamiques dont la plupart des checkouts dépendent. Cette même fragilité est l'une des raisons pour lesquelles la Content Security Policy ne fonctionne pas comme réponse PCI à elle seule. La surveillance runtime navigateur est la seule catégorie qui produit les quatre artefacts par elle-même, parce qu'elle observe le script comme le fait le navigateur de la victime.
Un plan d'achat qui teste la preuve, pas les fonctionnalités
Ne laissez pas une démo se terminer sur « regardez, il a attrapé le mauvais script ». Faites prouver à l'outil la paperasse.
- Montez une copie de staging d'une vraie page de paiement et connectez l'outil.
- Poussez un changement bénin sur un script, par exemple ajoutez un commentaire ou montez une version, et confirmez que l'outil le signale avec un diff avant/après, la page affectée, et un horodatage.
- Modifiez un en-tête HTTP de la page de paiement et confirmez que la détection de changement d'en-tête 11.6.1 se déclenche, et pas seulement la détection de contenu de script.
- Enregistrez une décision d'autorisation (approuvez un script, rejetez le changement) et confirmez que cet état est stocké, attribué et daté.
- Ajoutez un script qui ne se charge que pour une session ou une géographie spécifique et vérifiez si l'inventaire de l'outil le capture. C'est là que la couverture des scanners externes échoue, et une grande partie de la raison pour laquelle les crawlers ne peuvent pas aider à la conformité PCI à eux seuls.
- Exportez l'inventaire, les enregistrements d'autorisation, et le journal des changements. Lisez l'export comme le fera l'évaluateur. Si ce sont des captures d'écran ou un flux d'alertes sans étiquette, ce n'est pas une preuve.
Si un outil passe les étapes 2 à 6, il produit une documentation 6.4.3/11.6.1 prête pour l'audit. S'il s'arrête à l'étape 2, vous avez acheté de la surveillance, pas de la conformité.
Où cside s'insère dans le modèle de preuve
cside est une plateforme de client-side security conçue pour la catégorie de surveillance runtime navigateur, et spécifiquement pour la preuve qu'un QSA ouvre. Elle ne proxyfie pas le trafic. Un tag sur la page de paiement capture les scripts comme le vrai navigateur les exécute, ce qui ferme le trou du scanner sur le ciblage par session et par géographie.
Pour 6.4.3, PCI Shield maintient un inventaire en temps réel de chaque script de la page de paiement, y compris les scripts injectés dynamiquement et les scripts CDN tiers, avec un état d'autorisation par script. Pour 11.6.1, il alerte sur les changements non autorisés du contenu des scripts et des en-têtes HTTP de la page de paiement, avec un diff qui montre exactement ce qui a changé. Chaque ajout, changement, retrait et traitement d'alerte atterrit dans un journal de changements horodaté que vous pouvez exporter. cside a passé une évaluation QSA indépendante par VikingCloud pour 6.4.3 et 11.6.1, donc le modèle de preuve a été évalué, pas seulement affirmé. Au-delà de l'exigence, la plateforme ajoute la surveillance du comportement navigateur et la détection de bots et d'agents IA, de sorte que la même instrumentation qui produit votre enregistrement PCI fait aussi remonter les anomalies comportementales qu'un skimmer inédit crée.
Au 2026-06-18, considérez ceci comme une orientation opérationnelle, et non comme un conseil juridique. Confirmez le libellé exact des contrôles et ce que votre évaluateur acceptera comme preuve avec votre QSA, votre conseil juridique ou le responsable des risques.
