PCI DSS 6.4.3 : gérer les scripts de paiement

L'exigence 6.4.3 de PCI DSS vous oblige à rendre compte de chaque morceau de JavaScript qui s'exécute sur votre page de paiement. Elle existe parce que les skimmers de cartes (Magecart, formjacking, e-skimming) n'ont plus besoin de votre serveur : ils arrivent par un script que le navigateur de l'acheteur charge, lisent les champs de carte et en envoient une copie ailleurs. Vos journaux serveur ne voient rien.

L'exigence est obligatoire depuis le 31 mars 2025 et reste inchangée dans la version actuelle du standard, PCI DSS v4.0.1. Ce guide couvre ce qu'elle demande, qui elle concerne (y compris le changement du SAQ A de janvier 2025), les preuves qu'attend un évaluateur, et un modèle de justification à reprendre. Sa jumelle, PCI DSS 11.6.1, traite de la détection des changements une fois les scripts approuvés.

Le texte de l'exigenceCopy Anchor Link

PCI DSS v4.0.1 la formule ainsi (traduction de l'original anglais) :

Tous les scripts de page de paiement chargés et exécutés dans le navigateur du consommateur sont gérés comme suit :

• une méthode est mise en place pour confirmer que chaque script est autorisé ;
• une méthode est mise en place pour assurer l'intégrité de chaque script ;
• un inventaire de tous les scripts est tenu, avec une justification métier ou technique écrite expliquant pourquoi chacun est nécessaire.

Trois éléments, donc : l'autorisation, l'intégrité, et un inventaire assorti d'une justification. Le PCI Security Standards Council (PCI SSC) a publié en mars 2025 un supplément d'information sur la sécurité des pages de paiement qui détaille chacun d'eux. C'est la source primaire la plus utile sur le sujet, et celle que cet article cite tout du long.

Le glossaire PCI DSS définit largement le « script de page de paiement » : toute instruction d'un langage de programmation interprétée par le navigateur du consommateur sur une page de paiement, y compris celles qui agissent sur le DOM. JavaScript et WebAssembly en font partie, pas HTML ni CSS. Analytics, tests A/B, chat ou publicité : s'ils se chargent sur cette page, ce sont des scripts de page de paiement.

L'autorisationCopy Anchor Link

Il faut une méthode pour confirmer que chaque script est autorisé. Le supplément le dit clairement : le standard ne précise ni le fonctionnement de cette méthode, ni qui autorise dans l'entreprise, ni si le processus est manuel ou automatisé. Comme un script tiers peut changer à votre insu, l'autorisation peut intervenir avant l'ajout ou la modification d'un script, ou dès que possible après un changement.

L'intégritéCopy Anchor Link

Il faut une méthode pour garantir qu'un script n'a pas été altéré, à son introduction puis à chaque mise à jour. PCI DSS n'impose aucun mécanisme. Le supplément cite la Content Security Policy (CSP) et Subresource Integrity (SRI) comme exemples, et laisse la porte ouverte à d'autres :

• SRI fige un script sur un hash dans l'attribut integrity de la balise <script>. Cela fonctionne bien pour un fichier statique, mais le supplément juge SRI « peu pratique pour les scripts qui changent souvent », ce qui décrit la plupart des scripts de fournisseurs.
• Les hash et nonces CSP autorisent un contenu exact ou une balise précise. Le supplément note qu'un nonce ne surveille pas les changements internes d'un script déjà autorisé.
• Les hash observés : une CSP de niveau 3 avec 'report-sha256' fait remonter par le navigateur le hash SHA-256 de chaque script exécuté. Comparer ce hash à celui que vous avez approuvé constitue un contrôle d'intégrité qui fonctionne aussi pour les scripts qui évoluent.

L'inventaire et la justification écriteCopy Anchor Link

L'inventaire recense chaque script de la page de paiement, avec pour chacun une raison métier ou technique d'être là. Le standard ne dit pas comment le tenir. Le supplément indique que, « dans un environnement simple, un tableur peut suffire », et que les sites plus complexes s'appuient sur des outils automatisés ou des circuits de validation. Ce qui compte, c'est le résultat : uniquement des scripts connus et nécessaires sur la page.

L'exception 3DSCopy Anchor Link

Les scripts qu'un fournisseur 3-D Secure exécute pour réaliser l'authentification 3DS n'ont pas à être validés au titre de la 6.4.3, en raison de la relation de confiance établie entre ce fournisseur et le marchand. Tout script qui sort de ce cadre 3DS reste dans le périmètre.

Qui est concerné par la 6.4.3Copy Anchor Link

Tout dépend de la façon dont votre checkout reçoit la carte. Le tableau 3 du supplément répartit les rôles :

Trois points tranchent la plupart des cas réels :

• Intégrer une iframe ne sort pas la page parente du périmètre. Le supplément l'écrit noir sur blanc : intégrer le formulaire d'un tiers ne retire pas complètement du périmètre la page qui l'intègre, et ne rend pas 6.4.3 et 11.6.1 inapplicables. Un script de la page parente peut superposer un faux formulaire ou modifier l'adresse de l'iframe.
• Les scripts qui créent l'iframe ou déclenchent la redirection sont concernés. Si votre JavaScript construit l'iframe de paiement ou lance la redirection, ces scripts sont des scripts de page de paiement.
• Une single-page application élargit le périmètre. Dans une SPA, tout script chargé pendant la session reste en mémoire : 6.4.3 et 11.6.1 s'appliquent alors à toutes les vues de l'application susceptibles d'affecter le formulaire de paiement. Sur un site multipage classique, seule la page qui intègre le formulaire est en général concernée.

La 6.4.3 figure dans le SAQ A-EP, le SAQ D marchands, le SAQ D prestataires et le modèle de rapport de conformité (ROC).

Le SAQ A depuis janvier 2025Copy Anchor Link

La révision du SAQ A publiée en janvier 2025 a retiré 6.4.3 et 11.6.1 du questionnaire. À la place, elle ajoute un critère d'éligibilité pour les marchands e-commerce (original anglais) :

The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s).

Autrement dit, le marchand confirme que son site n'est pas exposé aux attaques par script susceptibles d'affecter ses systèmes e-commerce. La FAQ 1588 du PCI SSC (février 2025) explique comment y répondre. Le critère ne vise que les marchands dont la page intègre la page ou le formulaire de paiement d'un prestataire, par exemple dans une iframe. Il ne s'applique pas aux marchands qui redirigent vers le prestataire ou qui externalisent entièrement le paiement. Les marchands concernés ont deux options :

1. Appliquer à leur page des techniques comme celles de 6.4.3 et 11.6.1, eux-mêmes ou via un tiers.
2. Obtenir de leur prestataire de paiement, conforme PCI DSS, la confirmation que sa solution intégrée, mise en œuvre selon ses instructions, protège la page de paiement contre les attaques par script.

Un marchand SAQ A avec un formulaire intégré n'échappe donc pas au sujet. Soit il fait le travail de la 6.4.3 sur le fond, soit il détient une attestation écrite de son prestataire et suit ses consignes d'intégration. C'est votre acquéreur qui détermine le SAQ à remplir : vérifiez avec lui.

Iframes et champs hébergés : Stripe, Adyen et les autresCopy Anchor Link

Les champs hébergés (Stripe Elements et le Payment Element, Adyen Components et Drop-in, et leurs équivalents) placent la saisie de carte dans des iframes servies depuis l'origine du prestataire. Vos scripts ne peuvent pas lire l'intérieur d'une iframe cross-origin, d'où la réduction de périmètre. Elle n'est pas totale pour autant :

• Les scripts à l'intérieur des iframes relèvent du prestataire.
• Les scripts de votre page de checkout, y compris le script de chargement du prestataire (js.stripe.com, le Web SDK d'Adyen), sont à vous d'inventorier et de justifier.
• Si vous n'êtes pas en SAQ A, la 6.4.3 s'applique pleinement à cette page parente.

Les prestataires publient ce qu'il vous faut. Stripe liste les directives CSP nécessaires à chaque produit. Le guide de sécurité des scripts d'Adyen liste les domaines depuis lesquels ses composants chargent des scripts, publie les hash SRI de chaque version et recommande une CSP en report-only avec collecte des violations. Ces listes sont un bon point de départ pour votre inventaire et votre politique.

Si vous remplissez un SAQ A, demandez à votre prestataire la confirmation écrite décrite par la FAQ 1588, et classez-la avec vos documents de conformité.

Les gestionnaires de balises sur la page de paiementCopy Anchor Link

Un gestionnaire de balises est un script dont le rôle est d'en charger d'autres, souvent configuré par des équipes hors de l'informatique. Le supplément cite la gestion de balises parmi les types de scripts tiers qu'un attaquant peut détourner pour capter des données de paiement.

Si Google Tag Manager ou un autre conteneur se charge sur la page de paiement, le script du conteneur et chaque balise qu'il injecte sont des scripts de page de paiement. Chacun doit figurer à l'inventaire, avec une justification et une méthode d'intégrité. La solution la plus propre : ne pas charger le conteneur sur les pages de paiement, ou leur réserver un conteneur dédié avec une liste courte de balises revues. Voir comment les attaquants détournent Google Tag Manager pour les scénarios d'échec.

Les scripts de quatrième partieCopy Anchor Link

Le supplément rappelle que les serveurs tiers peuvent eux-mêmes charger des scripts depuis d'autres parties, « quatrièmes parties et au-delà ». Un widget de chat qui tire une bibliothèque de traduction, une balise analytics qui charge un utilitaire de son éditeur : voilà un script sur votre page de paiement que personne dans votre équipe n'a ajouté.

Ces scripts s'exécutent bien dans le navigateur du consommateur sur votre page de paiement, ils ont donc leur place dans l'inventaire. Relire votre HTML ne les fera pas apparaître : ils arrivent à l'exécution. La seule source complète, c'est le navigateur, et c'est pourquoi un inventaire construit à partir de ce que les navigateurs exécutent réellement attrape ce qu'une revue du code source manque. La FAQ sur les scripts de paiement détaille le volet pratique.

Les extensions de navigateurCopy Anchor Link

Les extensions installées par vos visiteurs injectent elles aussi des scripts dans votre checkout, et vous ne pouvez ni les autoriser ni les contrôler. Le supplément de mars 2025 ne parle pas des extensions, et nous n'avons trouvé aucune FAQ du PCI SSC qui le fasse. La lecture courante découle du texte : la 6.4.3 porte sur les scripts que votre page de paiement charge, et le script d'une extension est ajouté par le logiciel du visiteur lui-même.

Traitez les extensions comme hors périmètre, écrivez ce raisonnement dans votre procédure et validez-le avec votre évaluateur. Gardez un critère strict : si la page chargerait ce script pour un visiteur au profil de navigateur vierge, il est à vous et doit figurer à l'inventaire.

Les preuves qu'attend un QSACopy Anchor Link

Les tableaux 5 à 7 du supplément listent ce qu'un évaluateur attend pour la 6.4.3 :

• Des politiques et procédures de gestion des scripts de paiement couvrant les trois éléments, tenues à jour (exigence 6.1.1).
• Des rôles et responsabilités documentés et attribués : qui autorise les scripts, qui tient l'inventaire (exigence 6.1.2).
• Des personnes disponibles en entretien pour confirmer que les processus sont appliqués.
• Les enregistrements de l'inventaire, avec une justification technique ou métier par script.
• Des configurations système montrant les méthodes d'autorisation et d'intégrité de chaque script : l'en-tête CSP, les attributs SRI ou les réglages de l'outil de surveillance.

Le supplément donne des exemples de traces d'autorisation acceptables (une entrée dans un outil de workflow, de gestion des services ou de ticketing, ou un e-mail d'approbation conservé) et d'inventaires (un tableur, un document, une base de données, un gestionnaire de balises ou de scripts). Il précise que les preuves dépendent du caractère manuel ou automatisé de vos méthodes.

Ce qui bloque en pratique avec un évaluateur : des justifications qui ne disent rien (« nécessaire », « marketing »), un inventaire qui était vrai le trimestre dernier, des autorisations sans nom ni date.

Un modèle de justificationCopy Anchor Link

Une ligne par script. Les colonnes reprennent ce que demandent la 6.4.3 et ses procédures de test.

Rédigez chaque justification pour quelqu'un qui ne connaît pas votre stack : ce que fait le script, pourquoi il doit tourner sur cette page, qui en est responsable. Une ligne « rejeté » est tout aussi valable : elle prouve que la revue a eu lieu, à condition que le script soit ensuite réellement retiré.

Ce qu'apportent les rapports CSP et un inventaire continuCopy Anchor Link

Le supplément juge la CSP « assez efficace pour l'autorisation des scripts et, dans une certaine mesure, pour leur intégrité », tout en notant qu'à elle seule elle ne produit pas de liste des scripts non autorisés et ne conserve aucune référence (baseline). C'est là qu'intervient un collecteur de rapports.

Deux en-têtes font du navigateur la source de votre inventaire :

Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"

Content-Security-Policy-Report-Only: script-src 'self' https://js.stripe.com 'report-sha256'; report-to csp-endpoint

• Les rapports de violation arrivent de tous les navigateurs actuels dès qu'un script d'une origine absente de votre politique tente de se charger. C'est un signal d'autorisation : une source non approuvée, détectée dans une vraie session.
• Les rapports de hash (csp-hash) listent chaque script exécuté par un navigateur Chromium ou par Safari sur la page, avec son URL et, pour les scripts de même origine ou servis avec CORS, son hash SHA-256. Firefox ne les envoie pas encore : cette partie de l'inventaire reflète donc le trafic Chromium et Safari.
• Le mode report-only ne bloque rien : vous construisez l'inventaire sur un checkout en production sans risque, puis passez à une politique appliquée. Construire une CSP solide décrit ce chemin. Une politique stricte appliquée ressemble à ceci :

Content-Security-Policy: script-src 'nonce-{SERVER-GENERATED-NONCE}' 'strict-dynamic' 'report-sha256'; object-src 'none'; base-uri 'none'; report-to csp-endpoint

Un inventaire alimenté par les rapports est continu : un script qui se charge pour un acheteur sur mille, dans un seul pays, derrière un feature flag, apparaît dès que le navigateur de cet acheteur le signale, pas à la prochaine revue trimestrielle du tableur. Construire un inventaire de scripts avec les rapports de hash CSP détaille le format des rapports.

La place de CentralCSPCopy Anchor Link

CentralCSP construit l'inventaire de la 6.4.3 à partir de ces rapports, sans rien ajouter à la page de checkout. Vous définissez vos pages de paiement par motif d'URL, et chaque script observé y entre dans une file de revue. Chaque script reçoit une décision, justifié ou rejeté, avec un texte obligatoire, votre nom, la date et le hash concerné, consignée dans un journal en ajout seul. Quand le contenu d'un script justifié change, il repasse en Needs review au lieu de rester approuvé. Des règles d'inventaire approuvent par motif d'URL les prestataires déjà évalués, et les scripts injectés par des extensions de navigateur sont filtrés avant d'entrer dans l'inventaire.

Quand votre évaluateur le demande, l'export des preuves produit un ZIP contenant un rapport PDF et deux CSV complets : l'inventaire intégral et le journal des changements. Les données sont hébergées en France, chez OVH.

CentralCSP vous aide à répondre à la 6.4.3 ; il ne certifie pas la conformité, et c'est votre QSA qui juge si les preuves suffisent. Découvrez le fonctionnement sur la page PCI DSS, ou suivez le guide de démarrage PCI DSS.

Voir la surveillance des scripts PCI DSS

Questions fréquentesCopy Anchor Link

Une CSP suffit-elle pour la 6.4.3 ?Copy Anchor Link

Non. Une CSP est une méthode d'autorisation légitime et contribue à l'intégrité, mais la 6.4.3 exige aussi un inventaire écrit avec une justification pour chaque script : c'est un enregistrement, pas un en-tête. Le supplément du PCI SSC précise qu'il faut ajouter des processus complémentaires à la CSP.

La 6.4.3 s'applique-t-elle si j'utilise les champs hébergés de Stripe ou d'Adyen ?Copy Anchor Link

À votre page, oui. Les scripts à l'intérieur des iframes du prestataire relèvent de lui, mais ceux de la page qui les intègre relèvent de vous. Si vous remplissez un SAQ A, le critère d'éligibilité vous demande de confirmer que cette page n'est pas exposée aux attaques par script.

Peut-on automatiser la justification ?Copy Anchor Link

Le standard ne dit pas si l'autorisation doit être manuelle ou automatisée. Une règle qui approuve un prestataire évalué par son URL reste une décision écrite et attribuée. Un évaluateur vérifiera qu'une personne a défini la règle, qu'elle est étroite, et qu'un script modifié revient en revue au lieu de rester approuvé.

SourcesCopy Anchor Link

• PCI SSC, Payment Page Security and Preventing E-Skimming, Guidance for PCI DSS Requirements 6.4.3 and 11.6.1 (mars 2025), annonce
• PCI SSC, FAQ 1588, How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts?
• PCI SSC, bibliothèque documentaire (PCI DSS v4.0.1, SAQ A)
• Stripe, Integration security guide
• Adyen, Script security for ecommerce
• W3C, Content Security Policy Level 3
• WebKit, WebKit features in Safari 18.4 (Security)

Articles liésCopy Anchor Link

• PCI DSS 11.6.1 : détecter les changements sur les pages de paiement
• Scripts de paiement et PCI DSS : les questions que se posent les équipes
• Outils PCI DSS 6.4.3 et 11.6.1 comparés
• Construire un inventaire de scripts avec les rapports de hash CSP