Outils PCI DSS 6.4.3, choisir un inventaire des scripts de page de paiement

L'exigence 6.4.3 de PCI DSS v4 demande un inventaire de chaque script présent sur vos pages de paiement, chacun autorisé, justifié par écrit et contrôlé en intégrité. L'exigence 11.6.1 demande un mécanisme qui détecte la falsification de ces scripts et des headers HTTP de la page, tels que le navigateur du client les reçoit. Les deux sont obligatoires depuis le 31 mars 2025 et restent dans le standard actuel, la v4.0.1.

Les outils qui couvrent ces exigences observent la page de paiement de quatre façons : un agent JavaScript sur la page (Feroot, Source Defense, Jscrambler, cside), un proxy pour les scripts tiers (Evervault), un scan externe (Reflectiz, et la variante échantillonnée de Cloudflare), ou le reporting natif du navigateur (Report URI, CentralCSP). La façon dont un outil observe la page détermine ce qu'il voit, ce qu'il ajoute à votre checkout, et quelles preuves arrivent devant votre évaluateur de sécurité qualifié (QSA). Nous éditons CentralCSP, et les questions ci-dessous sont celles pour lesquelles nous l'avons conçu. Ce sont aussi celles que pose votre évaluateur.

CentralCSP construit l'inventaire à partir de deux headers de réponse, sans agent sur la page de paiement. Démarrez un essai gratuit et regardez-le se remplir depuis le trafic réel de votre checkout, ou lisez d'abord comment fonctionne le module PCI DSS.

Quoi demander à un outil d'inventaire des scripts de page de paiement

Posez ces questions avec votre QSA dans la pièce. Chacune correspond à une clause de 6.4.3 ou 11.6.1, et chacune sépare les modes de déploiement.

Voit-il chaque session réelle ?

11.6.1 nomme la page telle que le navigateur du consommateur la reçoit. Un script qui se charge pour un acheteur sur mille, dans un seul pays, derrière un seul feature flag, reste dans le périmètre. Un scan synthétique visite la page selon un planning avec le navigateur de l'éditeur ; une configuration échantillonnée voit une fraction des sessions.

CentralCSP utilise une capacité intégrée à la politique de sécurité du contenu (CSP) niveau 3. Le mot-clé 'report-sha256' demande au navigateur de hasher chaque script qu'il exécute et d'envoyer un rapport csp-hash. Chaque session réelle rapporte, scripts propriétaires et tiers confondus, avec un hash d'intégrité pour les scripts same-origin ou compatibles CORS. Le hash reporting n'existe aujourd'hui que dans les navigateurs Chromium ; les rapports de violation arrivent de tous les navigateurs actuels.

Qu'ajoute-t-il au checkout ?

Un agent est un script de plus sur la page de paiement, chargé en premier pour observer les autres. Il entre dans votre inventaire avec sa propre justification, et c'est une dépendance à l'exécution envers l'éditeur. Un proxy place le CDN de l'éditeur sur le chemin critique du checkout.

CentralCSP ajoute deux headers de réponse et rien sur la page. Vous déclarez l'endpoint avec Reporting-Endpoints et le référencez depuis la directive report-to de la politique :

Reporting-Endpoints: csp-endpoint="https://MyEndpoint.report.centralcsp.com"

Content-Security-Policy-Report-Only: script-src 'self' 'report-sha256'; report-to csp-endpoint

Si l'endpoint est injoignable, le checkout n'est pas affecté. Ce même header est le début d'une politique que vous pourrez appliquer plus tard.

Comment une justification est-elle enregistrée ?

6.4.3 veut une raison écrite par script. Demandez qui l'enregistre, si elle est horodatée et attribuée, et si elle peut être réécrite plus tard.

Dans CentralCSP, chaque script reçoit une décision, justifié ou rejeté, avec une raison écrite, votre nom, l'horodatage et le hash auquel elle s'applique. Les décisions entrent dans un registre en ajout seul, et une révision est une nouvelle entrée plutôt qu'une modification (justifier les scripts). Des règles approuvent les scripts de confiance par motif d'URL pour garder la revue courte, et un rejet reste toujours la décision d'une personne.

Que reçoit l'évaluateur ?

Demandez à voir le fichier réel. Chaque colonne doit répondre à une clause de 6.4.3 ou 11.6.1 plutôt qu'à un libellé marketing.

L'export des preuves de CentralCSP est un ZIP avec un rapport PDF et deux CSV complets : l'inventaire entier, scripts retirés compris, et l'intégralité du registre des changements. Le rapport indique qu'il traite les exigences 6.4.3 et 11.6.1 de PCI DSS v4.0.1. C'est une preuve que vous présentez ; votre QSA décide si elle suffit.

Comment vous prévient-il d'un changement ?

11.6.1 demande une détection de falsification au moins tous les sept jours. Une surveillance continue depuis les sessions réelles couvre la cadence, mais l'outil doit encore donner l'alerte.

CentralCSP alerte sur une nouvelle origine de script et sur un script non justifié sur une page de paiement, et un hash modifié renvoie le script en revue. Les alertes partent vers Slack, Microsoft Teams, Google Chat, Telegram, email ou un webhook (canaux d'alerte). CentralCSP observe et alerte ; c'est le navigateur, via votre CSP, qui bloque.

Où vivent les données ?

Les URL de pages de paiement, les hashes de scripts et les métadonnées de session quittent votre domaine. Obtenez la région d'hébergement et la liste des sous-traitants par écrit.

CentralCSP héberge les données de rapport dans l'UE chez OVH, avec une rétention fixe de 90 jours. CentralCSP remplit elle-même le SAQ A de PCI DSS, et l'accès est encadré par le SSO, le RBAC, la MFA et un journal d'audit.

Peut-on l'automatiser ?

Un programme de conformité vit dans des tickets, des pipelines, et de plus en plus dans un assistant IA. CentralCSP expose l'inventaire, les justifications et l'export via une API REST et un serveur MCP, donc une décision peut venir d'un script ou d'un assistant avec la même trace d'audit.

Peut-on commencer aujourd'hui ?

Le circuit d'achat entreprise existe quand vous en avez besoin, mais une démo obligatoire ne devrait pas être la seule voie pour une équipe plus petite qui prend la sécurité côté client au sérieux. CentralCSP est self-serve : créez un compte, ajoutez les deux headers, et l'inventaire se construit pendant que vous décidez.

Comment les autres outils observent la page

Agent. Feroot, Source Defense, Jscrambler Webpage Integrity et cside ajoutent un agent JavaScript à la page de paiement. Il s'exécute dans les sessions réelles, inventorie les scripts, et dans la plupart de ces produits observe aussi ce qu'un script fait, comme lire des champs de formulaire ; certains peuvent bloquer un comportement. Cette vue comportementale est la force du modèle, et l'agent sur le checkout en est le coût. Jscrambler décrit aussi un mode de surveillance sans agent.

Proxy. Evervault Page Protection ajoute un script de surveillance et fait transiter les requêtes de scripts tiers par le CDN d'Evervault, ce qui lui permet d'archiver chaque version et d'alerter sur un changement de source. Les scripts hébergés sur votre propre domaine ne sont pas suivis.

Scan externe. Reflectiz charge vos pages de paiement dans son propre navigateur isolé selon un planning, sans rien installer, et signale les changements entre deux passages ; les scripts qui ne se chargent que dans certaines sessions client sont la question à poser. Le client-side security de Cloudflare injecte un header CSP report-only dans un échantillon des réponses HTML qui passent par son proxy, il voit donc des sessions échantillonnées, pour les sites passés par le proxy Cloudflare.

Reporting natif du navigateur. Report URI Script Watch vient de la génération précédente des services de reporting CSP, pensée d'abord pour collecter. Il enregistre quand chaque script a été vu pour la première et la dernière fois et alerte quand quelque chose de nouveau apparaît. Demandez comment une justification écrite est enregistrée et ce que reçoit l'évaluateur.

Tableau comparatif

✅ couvert, 🟠 partiel ou à confirmer auprès de l'éditeur, ❌ absent. Agent : Feroot, Source Defense, Jscrambler, cside. Proxy : Evervault. Scan externe : Reflectiz. Header échantillonné : Cloudflare. Collecte seule : Report URI.

Les noms de produits appartiennent à leurs propriétaires. La comparaison repose sur la documentation publique de chaque éditeur au moment de la rédaction.

Quand une agence de notation signale la page de paiement

BitSight, SecurityScorecard et RiskRecon notent ce qu'elles voient de l'extérieur : un security header manquant, une politique de sécurité du contenu qui autorise tout. Les deux headers qui construisent l'inventaire sont aussi le début de la correction, parce qu'une politique report-only nourrie par le trafic réel est la voie vers une politique appliquée sans casser le checkout. Lancez le scanner de security headers gratuit sur la page, puis suivez comment corriger les constats CSP de BitSight ou comment corriger les constats CSP de SecurityScorecard.

Choisir le modèle, puis commencer

Si vous devez contrôler le comportement des scripts dans le navigateur, un agent le fait, et un script éditeur sur le checkout en est le prix. Si vous ne pouvez pas toucher à la page du tout, un scan externe est le départ le moins contraignant, avec la réserve des sessions synthétiques. Si vous voulez chaque session réelle, rien d'ajouté sur la page, et des preuves rédigées face au texte de l'exigence, le reporting natif du navigateur est conçu pour cela, et CentralCSP le transforme en workflow de revue et en export.

CentralCSP vous aide à répondre à 6.4.3 et 11.6.1 en produisant ces preuves ; c'est un QSA qui valide. Démarrez un essai gratuit, placez une politique report-only sur votre checkout, et l'inventaire et le registre sont prêts pour l'évaluateur. La page du module PCI DSS détaille la suite.

Sources

• PCI Security Standards Council, document library, PCI DSS v4.0.1
• MDN, guide de la politique de sécurité du contenu

Articles liés

• CSP et PCI DSS v4, répondre à 6.4.3 et 11.6.1 sur les pages de paiement
• La sécurité côté client de PCI DSS v4 expliquée aux responsables conformité
• Construire un inventaire de scripts avec le hash reporting CSP