--- title: "Scripts de paiement : inventaire PCI DSS 6.4.3 et 11.6.1" description: "Inventoriez chaque script de vos pages de paiement depuis le trafic réel, justifiez-le, soyez alerté des changements, exportez les preuves QSA. Sans agent." url: "https://centralcsp.com/fr/platform/pci-dss/" lang: "fr" --- PCI DSS 6.4.3 & 11.6.1 # Chaque script de votre page de paiement, inventorié et justifié. CentralCSP construit votre inventaire de scripts depuis le trafic navigateur réel, consigne la justification qu'exige 6.4.3, alerte à chaque changement et exporte les preuves que lit votre évaluateur. Rien de nouveau ne s'exécute sur votre checkout. [Démarrer l'essai gratuit](https://app.centralcsp.com) [Contacter le service commercial](https://centralcsp.com/fr/contact/?topic=sales) - PCI DSS v4.0.1 Exigences 6.4.3 et 11.6.1 - Rien sur votre page Ni agent, ni proxy - Preuves d'audit Export CSV et PDF - Résidence des données dans l'UE France, chez OVH PCI DSS v4.0.1, obligatoire depuis le 31 mars 2025 ## Ce que l'évaluation demande. Ce que vous remettez. Les exigences 6.4.3 et 11.6.1 existent parce que les skimmers de pages de paiement (e-skimming, Magecart, formjacking) s'exécutent entièrement dans le navigateur du visiteur et ne touchent jamais vos journaux serveur. Voici chaque clause, associée à l'artefact que CentralCSP produit pour elle. L'exigence 6.4.3 demande de gérer chaque script chargé et exécuté dans le navigateur du consommateur sur une page de paiement : confirmer que chacun est autorisé, garantir son intégrité, et tenir un inventaire avec une justification écrite, métier ou technique, pour chacun. L'exigence 11.6.1 demande un mécanisme de détection des changements et des altérations qui alerte votre équipe en cas de modification non autorisée des scripts, des en-têtes HTTP et du contenu de la page de paiement telle que reçue par le navigateur du consommateur, évalué au moins tous les sept jours. | L'exigence | Ce que CentralCSP produit | Statut | | --- | --- | --- | | 6.4.3 - Inventaire des scripts | Un inventaire de chaque script chargé sur vos pages de paiement, construit depuis ce que les navigateurs de vos visiteurs réels exécutent et maintenu à jour à chaque déploiement. Pas un tableur qui était vrai le trimestre dernier. | Couvert | | 6.4.3 - Autorisation | Chaque script porte un statut d'autorisation. Les nouveaux arrivent en attente de revue : rien ne reste sur la page sans être comptabilisé. | Couvert | | 6.4.3 - Justification écrite | Une justification métier ou technique consignée par script. Des règles auto-valident les motifs connus : une rotation de hash de routine ne repasse jamais en approbation manuelle. | Couvert | | 6.4.3 - Intégrité | Les hash des scripts sont suivis depuis le trafic réel. Quand le contenu change, le changement rejoint la chronologie et votre équipe est alertée. | Couvert | | 11.6.1 - Détection des changements et falsifications | Nouveaux scripts et nouvelles origines sur la page de paiement déclenchent une alerte dès que les navigateurs les rapportent : ajouts, changements et suppressions, datés. | Couvert | | 11.6.1 - Fréquence d'évaluation | Le plancher de l'exigence est hebdomadaire. Les rapports affluent en continu depuis le trafic de production : l'évaluation n'attend jamais un crawl planifié. | Couvert | | Preuves d'évaluation | Un seul export : l'inventaire, les justifications et l'historique des changements en CSV ou PDF, plus un SBOM des technologies et versions du site. | Couvert | ### Votre page de paiement, en chronologie. Chaque changement de script sur le checkout devient un événement daté : un fichier est apparu, un hash a tourné, une origine s'est montrée pour la première fois. Quand l'évaluateur demande ce qui a changé depuis l'an dernier, vous faites défiler. Vous ne reconstituez pas. - Un nouveau fichier de script sur la page - Un hash modifié sur un script que vous exécutez déjà - Une origine vue sur la page pour la première fois - Un script qui a disparu - Le registre de changements attendu par les revues 11.6.1 ### Justifiez une fois. Les règles absorbent le bruit. 6.4.3 veut une justification écrite pour chaque script. Consignez-la à la première apparition du script, puis laissez les règles d'auto-validation porter la routine : un motif connu qui fait tourner son hash se revalide seul, un fichier inconnu reste en attente jusqu'à ce qu'un humain regarde. - Justification écrite conservée par script - Règles d'auto-validation pour les motifs connus - Une file d'attente pour toute nouveauté ### Sachez de quoi vos scripts sont faits. CentralCSP identifie la bibliothèque et la version derrière chaque script, signale les CVE connues et les versions en fin de vie, et exporte le tout comme SBOM de votre site. Le jQuery vulnérable du checkout cesse d'être une découverte surprise. - Identification de la technologie et de la version - Signalement des CVE et fins de vie - Export SBOM du site entier ### L'alerte atteint l'équipe qui possède la page. Un nouveau script ou une nouvelle origine sur une page de paiement notifie Slack, Microsoft Teams, Google Chat, Telegram ou l'email dès qu'un navigateur le rapporte. Gardez la notification : entre deux évaluations, c'est la preuve que le contrôle fonctionne. - Alertes nouveau script et nouvelle origine, intégrées - 6 canaux, webhooks compris - Routées par site et par équipe Surveillance des scripts de page de paiement ## Quatre façons de traiter les exigences 6.4.3 et 11.6.1. Chacune peut passer une évaluation. Elles diffèrent par ce qu'elles voient, ce qu'elles ajoutent à la page de paiement et ce que les preuves coûtent à produire. Comparaison des approches pour PCI DSS 6.4.3 et 11.6.1 | | CentralCSP | Basé WAF | Crawl planifié | Proxy ou agent | | --- | --- | --- | --- | --- | | N'ajoute rien à la page de paiement | Rien d'ajouté à la page | Une dépendance en périphérie | Rien d'ajouté à la page | Nouvelle dépendance, nouveau point de défaillance | | Construit l'inventaire automatiquement | Automatique, depuis les navigateurs réels | N'exécute jamais la page | Seulement ce que le crawl a atteint | Depuis les sessions de son agent | | Alerte en cas de modification ou d'altération (11.6.1) | En continu, depuis le trafic réel | Aveugle dans le navigateur | Seulement à la cadence des scans | Tant que son agent tourne | | Fournit un workflow de justification (6.4.3) | Règles d'auto-validation intégrées | Absent | Variable selon le produit | Variable selon le produit | | Détecte les CVE et exporte un SBOM | Inclus, avec export SBOM | Pas pour les scripts de la page | Variable selon le produit | Rarement inclus | | Exporte des preuves prêtes pour l'audit | CSV / PDF en un clic | Journaux de requêtes bruts | Généralement exportable | Généralement exportable | Les preuves en données ## L'inventaire est interrogeable, pas une capture d'écran. Tout ce que le tableau de bord affiche est sur l'API REST : rapatriez l'inventaire des pages de paiement, les statuts de justification et l'historique des changements dans votre outillage GRC, ou laissez un agent piloter le tout via MCP. - API REST complète avec clés API de workspace - Exports CSV et PDF depuis le tableau de bord - Serveur MCP intégré pour les agents IA [Voir la plateforme API et MCP](https://centralcsp.com/fr/platform/api-mcp/) Comment ça marche ## Dix minutes pour l'installer. Des preuves dès qu'on les demande. Ni agent, ni SDK, ni changement du comportement du checkout. Les navigateurs rapportent nativement. 1. 01 - Connecter ### Ajoutez un en-tête de réponse. Créez votre site dans le tableau de bord et posez l'en-tête de reporting. Les navigateurs de vos visiteurs réels rapportent ce que la page de paiement charge en quelques minutes. 2. 02 - Justifier ### Passez l'inventaire en revue une fois. Approuvez ce qui a sa place, consignez pourquoi, posez les règles d'auto-validation. Ensuite, seuls les scripts réellement nouveaux réclament votre attention. 3. 03 - Prouver ### Exportez quand le QSA le demande. Inventaire, justifications et chronologie des changements en CSV ou PDF. Les preuves correspondent à ce qui a réellement tourné dans les navigateurs : la conversation est courte. Le tableau de bord ## Vos pages de paiement, sur un seul écran. Inventaire, justifications, changements et alertes pour chaque page de paiement, derrière un seul login. ![Le panneau de revue d'un script : son origine et son hash actuel, la justification écrite enregistrée, et l'historique daté de chaque changement de hash.](https://centralcsp.com/assets/script-justification-BWUbxL1V.webp) - Chaque script, avec son SHA-256 - Chaque changement, daté et attribué Adopté par des équipes du monde entier Tarifs ## Les fonctionnalités PCI DSS sont dans le plan Scale. La surveillance des pages de paiement, le workflow de justification, les exports de preuves et la détection de CVE font tous partie de Scale, en plus de tout Business : scans automatisés, alerting, API et MCP. - Inventaire des scripts des pages de paiement - Workflow de justification et règles d'auto-validation - Exports de preuves CSV et PDF - SBOM, CVE et signalement des fins de vie ### Scale Les preuves PCI DSS v4, à l'échelle d'un portefeuille. 349,99 € / mois - Applications 30 - Utilisateurs 100 - Rapports / mois 10 000 000 Tout ce qui est dans Business, plus : - Détection des CVE - Surveillance des pages de paiement - Preuves PCI DSS - SSO et journal d'audit - Facturation et accompagnement achats [Commencer](https://app.centralcsp.com/?plan=scale&billing=monthly) Pour aller plus loin ## Ce que demande un auditeur Ce que disent concrètement les exigences 6.4.3 et 11.6.1, et ce que contient l'export de preuves. - [Comment une CSP répond à 6.4.3 et 11.6.1](https://centralcsp.com/fr/blog/csp-pci-dss-v4) - [La sécurité client PCI DSS v4, expliquée](https://centralcsp.com/fr/blog/pci-dss-v4-client-side-explained) - [L'inventaire à partir des rapports de hash CSP](https://centralcsp.com/fr/blog/script-inventory) - [Ce que contient l'export de preuves](https://centralcsp.com/fr/docs/platform/features/pci-dss/evidence-export) - [Définir le périmètre des pages de paiement](https://centralcsp.com/fr/docs/platform/features/pci-dss/payment-pages) - [Les règles de justification automatique](https://centralcsp.com/fr/docs/platform/features/pci-dss/justification-rules) FAQ ## Questions fréquentes Ce que les marchands et leurs évaluateurs nous demandent, avec nos réponses. ### Que demande réellement l'exigence 6.4.3 de PCI DSS ? Que chaque script chargé et exécuté sur vos pages de paiement soit géré de trois façons : une méthode pour confirmer que chaque script est autorisé, une méthode pour assurer son intégrité, et un inventaire de tous les scripts avec une justification métier ou technique écrite pour chacun. CentralCSP produit ces trois enregistrements à partir de votre trafic navigateur réel. ### Une CSP ou SRI suffisent-elles pour la 6.4.3 ? Elles couvrent deux des trois clauses, pas la troisième. Une Content Security Policy autorise les origines qui peuvent charger un script, et un hash ou un nonce autorise un contenu exact : une CSP est donc une méthode d'autorisation légitime. Subresource Integrity vérifie que les octets d'un fichier statique sont bien ceux attendus : SRI est donc une méthode d'intégrité légitime. Aucune des deux ne produit la troisième chose que demande la 6.4.3 : un inventaire écrit, avec une justification métier ou technique pour chaque script. C'est un enregistrement, pas un en-tête. CentralCSP construit l'inventaire à partir des hash de scripts rapportés par les navigateurs et conserve la justification associée à chaque script : l'en-tête et le dossier viennent de la même source. ### À quelle fréquence le contrôle 11.6.1 doit-il tourner ? Le plancher est d'au moins une fois tous les sept jours, ou à une fréquence que vous définissez par une analyse de risque ciblée au titre de l'exigence 12.3.1. En pratique, ce plancher ne devient jamais la contrainte ici, parce que les rapports arrivent du trafic de production réel et non d'une tâche planifiée : un script modifié un mardi après-midi est évalué dès que le navigateur du premier visiteur le rapporte, pas à la prochaine exécution hebdomadaire. ### Qu'est-ce qui compte comme page de paiement ? Dans PCI DSS v4.0.1, toute page qui capture des données de compte, et les exigences couvrent aussi la page qui intègre une iframe de paiement. Si votre checkout encapsule l'iframe de votre prestataire, cette page englobante est dans le périmètre. Surveillez-la comme le formulaire lui-même. ### Les exigences 6.4.3 et 11.6.1 s'appliquent-elles aux marchands SAQ A ? La ligne de partage, c'est l'iframe. Un marchand qui intègre un formulaire de paiement dans une iframe sur sa propre page reste atteignable par un script sur cette page : la condition d'éligibilité liée à la susceptibilité aux scripts le concerne. Un marchand qui redirige entièrement l'acheteur vers une page de paiement hébergée n'est pas concerné du tout. Les marchands SAQ A-EP, dont la page influence la transaction, portent intégralement les exigences 6.4.3 et 11.6.1, sans condition d'éligibilité à examiner. Depuis la révision de janvier 2025, le SAQ A ne les liste plus, mais ses nouveaux critères d'éligibilité attendent que vous confirmiez que votre site n'est pas exposé aux attaques par script, ce qui en pratique revient à exécuter les mêmes contrôles ou à détenir une attestation de votre prestataire de paiement. Validez l'interprétation avec votre QSA ; CentralCSP vous fournit les preuves dans les deux cas. ### Quelle charge représente vraiment l'exigence de justification ? La première passe est le vrai travail : approuver chaque script de la page et consigner pourquoi il est là. Ensuite, les règles d'auto-validation absorbent la routine. Un script connu qui fait tourner son hash se revalide seul ; vous n'entendez parler que des fichiers et origines réellement nouveaux. ### La 11.6.1 couvre-t-elle aussi les en-têtes HTTP ? Oui. L'exigence est rédigée autour de la page de paiement telle que le navigateur du consommateur la reçoit, c'est-à-dire ses scripts, ses en-têtes HTTP et son contenu, pas seulement les scripts. CentralCSP alerte sur le versant scripts et origines à partir des rapports navigateur : un nouveau fichier, un hash modifié, une origine qui apparaît pour la première fois. Pour le versant en-têtes, le vérificateur d'en-têtes de sécurité gratuit note ce qu'une page envoie aujourd'hui, et la surveillance CSP suit l'en-tête de politique dans le temps une fois déployé. ### Quelles preuves mon QSA reçoit-il concrètement ? Un export CSV ou PDF de l'inventaire des pages de paiement avec la justification et le statut d'autorisation de chaque script, la chronologie datée des changements, et un SBOM des technologies, versions et CVE connues. C'est la liste d'artefacts que demandent les évaluateurs, générée depuis ce que les navigateurs ont réellement exécuté. ### CentralCSP ajoute-t-il de la latence au checkout, ou bloque-t-il quelque chose ? Ni l'un ni l'autre. Rien ne se charge sur votre page : les navigateurs envoient leurs rapports nativement via la Reporting API, la surveillance reste donc hors du chemin de service. L'application des règles reste le rôle de votre CSP, que CentralCSP vous aide à construire depuis les mêmes rapports. Ce que 11.6.1 exige pour les scripts des pages de paiement, la détection et l'alerte, c'est exactement ce qu'il fait. ## Arrivez à l'évaluation avec l'inventaire prêt. Connectez une page de paiement cet après-midi ; les navigateurs rapportent en quelques minutes. Aucun agent à déployer, rien d'ajouté au checkout. [Démarrer l'essai gratuit](https://app.centralcsp.com) [Contacter le service commercial](https://centralcsp.com/fr/contact/?topic=sales) --- Disponible en : [en](https://centralcsp.com/en/platform/pci-dss/), [fr](https://centralcsp.com/fr/platform/pci-dss/)