← Tous les articles

Scripts de paiement et PCI DSS : FAQ

CentralCSP Team

CentralCSP ·

Voici les questions que les équipes e-commerce et conformité posent le plus souvent sur les exigences PCI DSS 6.4.3 (gérer chaque script de la page de paiement) et 11.6.1 (détecter les changements de scripts et d'en-têtes). Chaque réponse est courte et renvoie à la source primaire, en premier lieu le supplément d'information du PCI SSC Payment Page Security and Preventing E-Skimming (mars 2025), appelé « le supplément » ci-dessous.

Rien de tout cela ne remplace votre évaluateur. Quand une réponse relève de l'interprétation, elle le dit.

Le périmètre

Quelles pages sont concernées par 6.4.3 et 11.6.1 ?

La page de paiement elle-même, et toute page qui intègre un formulaire de paiement dans une iframe (la « page parente »). Le supplément précise qu'intégrer le formulaire d'un prestataire ne sort pas la page parente du périmètre. Une page qui se contente de rediriger l'acheteur vers la page hébergée du prestataire n'est pas concernée par ces deux exigences, mais les scripts qui effectuent la redirection le sont. Dans une single-page application, toutes les vues susceptibles d'affecter le formulaire de paiement sont concernées, car les scripts restent chargés d'une vue à l'autre.

Les iframes ou champs hébergés (Stripe, Adyen) me sortent-ils du périmètre ?

Ils le réduisent sans le supprimer. Les scripts à l'intérieur de l'iframe du prestataire relèvent de lui. Les scripts de votre page qui contient l'iframe, y compris le script de chargement du prestataire comme js.stripe.com, relèvent de vous. Si l'un de vos scripts crée l'iframe, c'est un script de page de paiement. Le guide de sécurité des scripts d'Adyen liste les domaines depuis lesquels ses composants chargent et publie les hash SRI de chaque version ; Stripe liste ses directives CSP. Deux bonnes bases pour votre inventaire.

Faut-il inclure les scripts des extensions de navigateur dans le périmètre PCI DSS ?

En général non, mais écrivez pourquoi. Le supplément ne mentionne pas les extensions, et nous n'avons trouvé aucune FAQ du PCI SSC à leur sujet. La 6.4.3 porte sur les scripts que votre page de paiement charge ; le script d'une extension est injecté par le logiciel du visiteur, que vous ne pouvez ni autoriser ni contrôler. Consignez cette position dans votre procédure de gestion des scripts et validez-la avec votre évaluateur.

Comment exclure les extensions sans masquer de vrais scripts ?

Appliquez un critère de propriété, pas d'agacement : la page chargerait-elle ce script pour un visiteur au profil de navigateur vierge ? Si oui, il est à vous et reste à l'inventaire. Les scripts d'extension se reconnaissent en général à leur schéma d'URL (chrome-extension://, moz-extension://, safari-web-extension://), ce qui les rend faciles à filtrer. Soyez plus prudent avec les logiciels qui semblent externes mais arrivent par le réseau, comme un proxy de traduction ou une surcouche d'accessibilité : ne les excluez qu'avec une règle étroite et documentée. Dans CentralCSP, les scripts d'extension sont filtrés avant d'entrer dans l'inventaire, et les autres logiciels côté visiteur peuvent être exclus par une règle d'exclusion dont le motif figure dans le dossier de preuves.

Les gestionnaires de balises sont-ils concernés ?

Oui, si le conteneur se charge sur une page de paiement. Le script du conteneur et chaque balise qu'il injecte sont des scripts de page de paiement, chacun avec son entrée d'inventaire, sa justification et sa méthode d'intégrité. Le supplément cite la gestion de balises parmi les types de scripts tiers que les attaquants peuvent détourner. Le contrôle le plus simple : garder le conteneur hors des pages de paiement, ou réserver au checkout un conteneur dédié, court et revu.

Les scripts 3-D Secure comptent-ils ?

Non, pour la 6.4.3. Le supplément exempte les scripts que le fournisseur 3DS exécute pour réaliser l'authentification, en raison de la relation de confiance établie avec le marchand. Tout script exécuté à une autre fin reste dans le périmètre.

Le SAQ A

Les exigences 6.4.3 et 11.6.1 s'appliquent-elles aux marchands SAQ A ?

Plus en tant qu'exigences listées depuis la révision du SAQ A de janvier 2025. À la place, le SAQ A comporte un critère d'éligibilité : le marchand confirme que son site n'est pas exposé aux attaques par script susceptibles d'affecter ses systèmes e-commerce (« The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s) »).

Suis-je toujours éligible au SAQ A, et comment confirmer le critère sur les scripts ?

C'est votre acquéreur qui décide du SAQ à remplir. D'après la FAQ 1588 du PCI SSC, le critère ne vise que les marchands dont la page intègre la page ou le formulaire de paiement d'un prestataire (une iframe par exemple), pas ceux qui redirigent ou externalisent entièrement. Deux façons d'y répondre : appliquer à votre page des techniques comme celles de 6.4.3 et 11.6.1, ou obtenir de votre prestataire, conforme PCI DSS, la confirmation que sa solution intégrée, mise en œuvre selon ses instructions, protège votre page contre les attaques par script. Gardez cette confirmation par écrit.

Construire et tenir l'inventaire

Comment inventorier les scripts de quatrième partie chargés par les fournisseurs ?

Depuis le navigateur. Le supplément rappelle que les serveurs tiers peuvent charger des scripts d'autres parties, « quatrièmes parties et au-delà ». Ils n'apparaissent ni dans votre HTML ni dans votre build, seulement à l'exécution. Trois façons de les voir :

  • Les rapports de hash CSP : ajoutez 'report-sha256' à script-src et un point de collecte report-to. Les navigateurs Chromium et Safari signalent alors chaque script exécuté sur la page, par URL, quel que soit celui qui l'a chargé. Commencez en mode Content-Security-Policy-Report-Only pour ne rien casser.
  • Les rapports de violation CSP : un script venant d'une origine absente de votre politique déclenche un rapport depuis n'importe quel navigateur actuel.
  • Une session de navigateur : l'onglet Réseau des outils de développement, ou un crawl headless, montre ce qu'une session a chargé. Utile pour un premier aperçu, insuffisant comme inventaire.

Construire un inventaire de scripts avec les rapports de hash CSP détaille les en-têtes et le format des rapports.

Comment tenir l'inventaire à jour sans tableur ?

Construisez-le à partir de ce que les navigateurs signalent plutôt que de ce dont quelqu'un se souvient. Un inventaire alimenté par les rapports se met à jour dès qu'une vraie session charge un nouveau script, et un hash modifié renvoie un script approuvé en revue. Le supplément admet le tableur pour les sites simples ; le problème, c'est qu'un tableur est une photo à un instant donné, alors que les scripts tiers changent sans prévenir. Si vous en gardez un, confrontez-le aux données navigateur au moins aussi souvent que votre cadence 11.6.1.

Comment justifier chaque script de la page de paiement ?

Une ligne par script, qui répond à quatre questions : que fait-il, pourquoi doit-il tourner sur cette page, qui en est responsable, comment son intégrité est-elle assurée. « Stripe.js tokenise les champs de carte, indispensable au paiement, responsable : équipe paiement » est une justification. « Nécessaire » n'en est pas une. Si vous ne trouvez pas de raison qu'un inconnu accepterait, la réponse honnête est de retirer le script. Le guide de la 6.4.3 propose un tableau modèle à reprendre.

Que pensent les évaluateurs de la justification automatisée ?

PCI DSS n'impose pas que l'autorisation ou la justification soient manuelles. Le supplément indique que le standard ne précise pas si le processus est manuel ou automatisé, et que les preuves dépendent des méthodes employées. Savoir si une approche automatisée donnée suffit relève de votre évaluateur. En pratique, une approbation automatique tient quand une personne identifiée a défini la règle, que la règle est étroite (un fournisseur, un chemin), que son motif écrit est précis, et qu'un script dont le contenu change revient en revue humaine au lieu de rester approuvé.

Les preuves

Quelles preuves un QSA attend-il pour 6.4.3 et 11.6.1 ?

Pour la 6.4.3 : des politiques et procédures de gestion des scripts, des rôles documentés, des personnes disponibles en entretien, l'inventaire avec ses justifications, et des configurations montrant comment chaque script est autorisé et son intégrité assurée. Pour la 11.6.1 : les réglages du mécanisme, la liste des pages surveillées, les résultats de surveillance, la preuve qu'il alerte, la fréquence (et l'analyse de risque ciblée si elle est inférieure à hebdomadaire), plus l'entrée du plan de réponse aux incidents pour ces alertes. Les tableaux 5 à 10 du supplément les détaillent.

Quel est le moyen le plus rapide de produire un rapport d'inventaire PCI ?

Si vous collectez déjà des rapports CSP, exportez ce que vous avez. Dans CentralCSP, l'export des preuves produit un ZIP avec un rapport PDF et deux CSV complets (l'inventaire et le journal des changements), et le CSV de l'inventaire s'exporte en un clic depuis la liste des scripts. Si vous partez de zéro, le chemin le plus rapide et honnête : une CSP en report-only avec 'report-sha256' sur le checkout, quelques jours de trafic réel, puis une séance de revue pour rédiger les justifications. Le guide de démarrage déroule les étapes.

Quels outils automatisent la conformité PCI DSS des pages de paiement ?

Ils se rangent en quatre familles : agents sur la page, proxys ou fonctions CDN, scanners synthétiques planifiés, collecteurs de rapports CSP, sans oublier l'approche manuelle. Outils PCI DSS 6.4.3 et 11.6.1 comparés expose ce que voit chacun et les preuves qu'il produit.

La place de CentralCSP

CentralCSP construit l'inventaire des pages de paiement à partir des rapports CSP, sans rien ajouter au checkout, consigne une décision écrite par script dans un journal en ajout seul, alerte quand un script non justifié apparaît ou qu'un script change de contenu, et exporte le dossier de preuves. Il est hébergé en France. Il vous aide à répondre à 6.4.3 et 11.6.1 ; c'est votre QSA qui tranche. Voir la page PCI DSS.

Sources

Articles liés