PCI DSS 6.4.3 et 11.6.1 expliqués : stopper le skimming des pages de paiement

Un skimmer ne s’introduit pas dans votre base de données. Il édite un script sur votre page de paiement pour que le navigateur du client envoie le numéro de carte à l’attaquant en route vers le processeur. PCI DSS v4.0.1 a ajouté deux exigences ciblant exactement cette attaque — l’une pour contrôler les scripts, l’autre pour détecter leur modification.

Le skimming de page de paiement (Magecart et ses cousins) fonctionne parce que les pages de paiement modernes s’assemblent dans le navigateur du client depuis des scripts chargés de nombreuses sources — analytique, tag managers, chat, pubs. Chaque script peut lire les champs du formulaire. Un attaquant qui injecte ou altère un script exfiltre les données de carte avant qu’elles n’atteignent votre serveur. Les contrôles côté serveur traditionnels ne le voient pas ; l’altération se fait dans le navigateur.

PCI DSS v4.0.1 répond avec deux exigences appariées. 6.4.3 gère les scripts qui s’exécutent sur la page de paiement. 11.6.1 détecte quand ces scripts sont modifiés sans autorisation. Les deux étaient bonnes pratiques jusqu’au 31 mars 2025 et sont désormais exigées. Cet article explique ce que chacune demande et comment une PME implémente les deux.

Exigence 6.4.3 — gérer chaque script sur la page de paiement

L’exigence dit que tous les scripts de page de paiement chargés et exécutés dans le navigateur du consommateur doivent être gérés trois façons :

• **Une méthode pour confirmer que chaque script est autorisé.** Chaque script — interne et tiers — est explicitement approuvé avant de s’exécuter. L’approbation peut être une validation manuelle ou un flux automatisé ; la norme accepte les deux.
• **Une méthode pour assurer l’intégrité de chaque script.** Le script n’a pas pu être altéré entre votre intention et l’exécution par le navigateur.
• **Un inventaire de tous les scripts, avec justification écrite opérationnelle ou technique pour chacun.** Un script sans justification est un script qui ne devrait pas être là. L’inventaire est l’artefact que l’évaluateur révise.

L’objectif d’approche personnalisée énonce l’intention clairement : « Du code non autorisé ne peut pas s’exécuter dans la page de paiement telle qu’elle est rendue dans le navigateur du consommateur. » Le mécanisme vous appartient ; le résultat, non.

Comment une PME l’implémente :

1. Bâtir l’inventaire des scripts. Listez chaque script que la page de paiement charge — bundles internes, le tag manager, l’analytique, le chat, les scripts de fraude, les scripts du processeur. Pour chacun, écrivez une ligne sur pourquoi il est nécessaire. Cet inventaire est la fondation ; sans lui, les deux autres parties ne se font pas. 2. Autoriser les scripts via un flux. Un tag manager avec étape d’approbation, ou un pipeline de contenu revu en changement, pour qu’un script ne puisse être ajouté sans validation. L’autorisation peut être confirmée après un changement « dès que possible » quand la pré-approbation est impraticable — la norme le permet, mais la confirmation doit avoir lieu. 3. Renforcer l’intégrité avec SRI et CSP. Sub-resource Integrity (SRI) laisse le navigateur valider qu’un script n’a pas été altéré en vérifiant un hachage. Une Content Security Policy (CSP) limite les origines depuis lesquelles le navigateur peut charger des scripts et transmettre des données de compte. Ensemble, c’est le mécanisme d’intégrité recommandé par la norme, et il est gratuit. 4. Utiliser l’exception iframe quand elle s’applique. Si vous intégrez le formulaire de paiement du processeur dans un iframe, les scripts à l’intérieur de l’iframe relèvent du processeur, pas de vous. La norme est explicite : l’entité « devrait s’attendre à ce que le TPSP/processeur fournisse une preuve » qu’il satisfait 6.4.3. Obtenez cette preuve par écrit. Vos scripts sur la page parente restent dans le périmètre ; ceux de l’iframe, non.

Exigence 11.6.1 — détecter l’altération sur la page de paiement

Là où 6.4.3 prévient les scripts non autorisés, 11.6.1 les détecte quand même — défense en profondeur. L’exigence dit qu’un mécanisme de détection de changement et d’altération est déployé pour :

• **alerter le personnel sur toute modification non autorisée** des en-têtes HTTP à impact de sécurité et du contenu des scripts de la page de paiement **tels que reçus par le navigateur du consommateur**,
• **évaluer les en-têtes HTTP et la page de paiement reçus** (pas seulement la source côté serveur), et
• **s’exécuter au moins hebdomadairement, ou à une fréquence définie par une analyse de risque ciblée** menée selon l’exigence 12.3.1.

L’expression clé est « tels que reçus par le navigateur du consommateur. » La détection de changement côté serveur manque l’injection côté client ; le mécanisme doit regarder ce que le navigateur reçoit réellement. L’objectif d’approche personnalisée : « Du code ou des techniques de skimming e-commerce ne peuvent pas être ajoutés aux pages de paiement telles que reçues par le navigateur du consommateur sans qu’une alerte opportune soit générée. Les mesures anti-skimming ne peuvent pas être retirées des pages de paiement sans qu’une alerte prompte soit générée. »

Comment une PME l’implémente :

1. Rapport de violations CSP. Configurez la directive CSP report-to ou report-uri pour que les violations (un script tentant de charger depuis une origine non approuvée) soient envoyées vers un collecteur que vous surveillez. Les violations CSP sont un signal d’altération gratuit et intégré. 2. Surveiller la CSP elle-même. Un changement de CSP est lui-même une altération — un attaquant qui relâche la politique avant d’injecter. Alerte sur les changements de CSP. 3. Surveillance utilisateur synthétique. Un service externe qui demande périodiquement la page de paiement depuis internet et compare les scripts et en-têtes reçus à une base de référence connue. C’est le contrôle « tel que reçu par le navigateur », et c’est typiquement un abordable pour une PME. 4. Script de détection d’altération. Un script résistant à l’altération intégré à la page de paiement qui alerte (et peut bloquer) quand il détecte un comportement de script malveillant. Souvent groupé avec le fournisseur de surveillance synthétique. 5. Fixer la fréquence. Hebdomadaire au minimum, ou documentez une analyse de risque ciblée justifiant une cadence différente. La TRA est un artefact de l’exigence 12.3.1 — voir l’article modèle de TRA.

Comment les deux exigences s’articulent

6.4.3 et 11.6.1 forment une paire : 6.4.3 réduit la surface de scripts et verrouille l’intégrité des scripts approuvés ; 11.6.1 surveille le résultat pour que si un script est ajouté ou altéré quand même, quelqu’un soit alerté sous une semaine. Faire l’une sans l’autre laisse un écart — scripts autorisés sans détection d’altération manquent un CDN fournisseur compromis ; détection d’altération sans gestion de scripts noie sous des alertes de scripts que personne n’a autorisés.

Le mécanisme commun est la CSP : elle renforce l’autorisation (seulement les origines approuvées) et produit des rapports de violation (détection d’altération). Une CSP bien bâtie fait l’essentiel des deux exigences à la fois.

L’interaction avec la réduction de périmètre

Si vous externalisez la page de paiement vers un formulaire hébergé par le processeur ou un terminal P2PE, ces exigences passent largement au processeur — les notes d’applicabilité de la norme confirment que le TPSP est responsable des scripts dans son iframe intégré. C’est le même levier que la réduction de périmètre : la façon la moins chère de satisfaire 6.4.3 et 11.6.1 est de ne pas avoir sa propre page de paiement. Quand vous devez en gérer une, le chemin inventaire-plus-CSP-plus-surveillance ci-dessus est l’implémentation.

Comment cela s’intègre dans la série

C’est le compagnon approfondi du pilier PCI DSS, apparié avec la réduction de périmètre — les deux réduisent la surface d’attaque paiement. Il alimente le guide du SAQ (ces exigences figurent sur les SAQ e-commerce) et le modèle de TRA (la fréquence de 11.6.1 nécessite une TRA).

Que faire ensuite

Bâtissez l’inventaire des scripts de votre page de paiement cette semaine — c’est l’artefact dont les deux exigences dépendent, et il est gratuit. Puis ajoutez une CSP avec report-to, confirmez SRI sur vos scripts internes, et mettez en place soit une surveillance synthétique soit un script de détection d’altération. L’inventaire plus la CSP vous mène la majeure partie du chemin vers la conformité ; la surveillance ferme la moitié détection.

Vous voulez une revue des contrôles anti-skimming avant votre évaluation ? Réservez une **revue de réduction de périmètre PCI + préparation** de 30 min — nous auditons vos scripts de page de paiement contre 6.4.3, vérifions votre CSP et votre surveillance contre 11.6.1, et vous remettons la liste des écarts. Bilingue FR/EN, sans obligation.

→ /fr/pci-dss-evaluation/