Question 1

Que demande réellement l'exigence 6.4.3 de PCI DSS ?

Accepted Answer

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.

Question 2

Une CSP ou SRI suffisent-elles pour la 6.4.3 ?

Accepted Answer

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.

Question 3

À quelle fréquence le contrôle 11.6.1 doit-il tourner ?

Accepted Answer

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.

Question 4

Qu'est-ce qui compte comme page de paiement ?

Accepted Answer

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.

Question 5

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

Accepted Answer

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.

Question 6

Quelle charge représente vraiment l'exigence de justification ?

Accepted Answer

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.

Question 7

La 11.6.1 couvre-t-elle aussi les en-têtes HTTP ?

Accepted Answer

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é.

Question 8

Quelles preuves mon QSA reçoit-il concrètement ?

Accepted Answer

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é.

Question 9

CentralCSP ajoute-t-il de la latence au checkout, ou bloque-t-il quelque chose ?

Accepted Answer

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.

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

	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

Chaque script de votre page de paiement, inventorié et justifié.

Ce que l'évaluation demande. Ce que vous remettez.

Votre page de paiement, en chronologie.

Justifiez une fois. Les règles absorbent le bruit.

Sachez de quoi vos scripts sont faits.

L'alerte atteint l'équipe qui possède la page.

Quatre façons de traiter les exigences 6.4.3 et 11.6.1.

L'inventaire est interrogeable, pas une capture d'écran.

Dix minutes pour l'installer. Des preuves dès qu'on les demande.

Ajoutez un en-tête de réponse.

Passez l'inventaire en revue une fois.

Exportez quand le QSA le demande.

Vos pages de paiement, sur un seul écran.

Les fonctionnalités PCI DSS sont dans le plan Scale.

Scale

Ce que demande un auditeur

Questions fréquentes

Arrivez à l'évaluation avec l'inventaire prêt.