--- title: "PCI DSS 6.4.3 et 11.6.1 : scripts des pages de paiement" description: "Inventoriez les scripts de vos pages de paiement depuis le trafic réel, justifiez chacun, soyez alerté des changements et exportez les preuves pour le QSA." url: "https://next.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.next.centralcsp.com) [Contacter le service commercial](https://next.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 Les exigences ## Ce que l'évaluation demande. Ce que vous remettez. Les exigences 6.4.3 et 11.6.1 sont obligatoires à chaque évaluation depuis le 31 mars 2025. Voici chaque clause, associée à l'artefact que CentralCSP produit pour elle. | 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. - Ajouts, changements et retraits, datés - Historique par page pour chaque page de paiement - 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 - 5 canaux plus webhooks - Routées par site et par équipe Approches ## Trois façons de tenir 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 | Proxy ou agent | | --- | --- | --- | --- | | N'ajoute rien à la page de paiement | Oui: Rien d'ajouté à la page | Partiellement: Une dépendance en périphérie | Non: Nouvelle dépendance, nouveau point de défaillance | | Construit l'inventaire automatiquement | Oui: Automatique, depuis les navigateurs réels | Non: N'exécute jamais la page | Partiellement: Depuis les sessions de son agent | | Alerte en cas de modification ou d'altération (11.6.1) | Oui: En continu, depuis le trafic réel | Non: Aveugle dans le navigateur | Oui: Tant que son agent tourne | | Fournit un workflow de justification (6.4.3) | Oui: Règles d'auto-validation intégrées | Non: Absent | Partiellement: Variable selon le produit | | Détecte les CVE et exporte un SBOM | Oui: Inclus, avec export SBOM | Non: Pas pour les scripts de la page | Non: Rarement inclus | | Exporte des preuves prêtes pour l'audit | Oui: CSV / PDF en un clic | Non: Journaux de requêtes bruts | Partiellement: 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 tokens à portée limitée - Exports CSV et PDF depuis le tableau de bord - Serveur MCP intégré pour les agents IA [Voir la plateforme API et MCP](https://next.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. MyEndpoint.report.centralcsp.com 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. 6.4.3 11.6.1 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 tableau de bord CentralCSP : rapports en direct et inventaire des scripts d'une page de paiement.](https://next.centralcsp.com/assets/hero-dashboard-KiR2e_Kc.webp) - Rapports en direct des visiteurs réels - Inventaire des scripts par page de paiement - Alertes immédiates sur les nouveaux scripts - Preuves PCI prêtes pour l'audit Adopté par des équipes du monde entier 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. ### 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 ? 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. ### 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.next.centralcsp.com) [Contacter le service commercial](https://next.centralcsp.com/fr/contact/?topic=sales) --- Disponible en : [en](https://next.centralcsp.com/en/platform/pci-dss/), [fr](https://next.centralcsp.com/fr/platform/pci-dss/)