CSP et PCI DSS v4, répondre à 6.4.3 et 11.6.1 sur les pages de paiement

PCI DSS v4 a ajouté deux exigences visant directement le navigateur : 6.4.3 et 11.6.1. Les deux sont devenues obligatoires le 31 mars 2025 et restent en vigueur dans la version actuelle du standard, la v4.0.1. Elles concernent les scripts et les headers HTTP de vos pages de paiement, l'endroit où un skimmer Magecart vole les données de carte (ce que sont Magecart et le formjacking). Une politique de sécurité du contenu (CSP), un header de réponse HTTP qui indique au navigateur quels scripts peuvent s'exécuter, combinée à un inventaire de scripts, une alerte sur changement et un reporting des violations, vous donne les preuves de gestion et de détection de falsification que ces exigences demandent. CentralCSP vous aide à répondre à 6.4.3 et 11.6.1 en produisant ces preuves ; il ne certifie pas la conformité. C'est votre QSA qui valide.

Cet article explique en termes clairs ce que demande chaque exigence et comment les contrôles côté navigateur y répondent. Si vous êtes responsable de la conformité plutôt que du code, lisez plutôt PCI DSS v4 côté client pour le responsable conformité. CentralCSP fournit l'inventaire de scripts et la surveillance des changements de headers et de scripts sur lesquels reposent les preuves attendues ; la correspondance exacte entre une fonctionnalité et un point d'exigence est à caler avec votre évaluateur, ce n'est pas une certification.

Les deux exigences en termes clairs

Les deux exigences s'appliquent aux pages qui manipulent les données de carte de paiement dans le navigateur du consommateur (les pages de checkout et de paiement), et aux scripts qui s'y chargent et s'y exécutent.

6.4.3, gérer et autoriser les scripts de la page de paiement

L'exigence 6.4.3 vous demande de gérer tous les scripts qui se chargent dans la page de paiement. En pratique, cela veut dire trois choses : vous tenez un inventaire de chaque script avec une justification écrite de sa nécessité, vous autorisez chaque script avant qu'il ne s'exécute, et vous avez une méthode pour garantir l'intégrité de chaque script. L'intention est qu'aucun script ne s'exécute sur votre page de paiement sans que vous l'ayez sciemment approuvé.

11.6.1, détecter la falsification et le changement non autorisé

L'exigence 11.6.1 vous demande de déployer un mécanisme de détection de changement et de falsification sur la page de paiement qui vous alerte de toute modification non autorisée des headers HTTP et du contenu des scripts tels que reçus par le navigateur du consommateur. Elle fixe aussi une cadence : le mécanisme évalue la page au moins une fois tous les sept jours, ou selon une fréquence définie par votre propre analyse de risque. L'intention est que si un attaquant modifie un header ou un script sur la page de paiement, vous l'appreniez rapidement.

Prises ensemble : 6.4.3 demande de connaître et d'autoriser ce qui doit être là, 11.6.1 demande d'être averti quand quelque chose change.

Comment une CSP et la surveillance côté client y répondent

Ce sont des exigences côté navigateur, donc les preuves doivent venir de ce que le navigateur charge et exécute réellement, pas de vos logs serveur. C'est exactement ce que fournissent une CSP et son reporting.

Connaître et autoriser les scripts (6.4.3)

Un inventaire de scripts construit à partir du hash reporting CSP liste chaque script qui s'exécute sur la page de paiement, avec la technologie, la version et les CVE connues derrière chacun. Cet inventaire, complété d'une justification enregistrée pour chaque script, constitue la liste inventoriée et autorisée que demande 6.4.3. Une CSP stricte, c'est le volet application : une politique à nonce avec 'strict-dynamic' n'exécute que les scripts que vous avez marqués, ce qui est le mécanisme d'autorisation dans le navigateur, et les hashes CSP ou Subresource Integrity vous donnent la garantie d'intégrité sur les scripts que vous autorisez.

Détecter le changement et la falsification (11.6.1)

Le reporting des violations et l'alerte sur changement couvrent 11.6.1. Chaque fois que le navigateur bloque ou signale un script ou une ressource modifiée sur la page de paiement, le rapport arrive dans votre collecteur. L'alerte sur changement se déclenche quand l'ensemble des scripts ou les headers de réponse de la page diffèrent de la ligne de base approuvée : une nouvelle origine, un nouveau bloc inline, un script qui n'était pas là avant, ou un security header modifié. Comme les rapports proviennent de vrais navigateurs qui chargent la page, ils la reflètent telle que le consommateur la reçoit, c'est-à-dire exactement le point de vue que vise 11.6.1.

Voici à quoi ressemble le branchement de la politique et du reporting sur une page de paiement :

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

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

Construire cette politique sans rien casser est un chantier à part entière ; voyez comment construire une CSP solide pour l'approche Report-Only d'abord.

Une vue d'ensemble de la conformité, avec la couverture de revue et les scripts en attente de décision

Ce que « vous aide à répondre » signifie ici

CentralCSP vous donne les contrôles et les enregistrements qui satisfont l'intention de 6.4.3 et 11.6.1 : l'inventaire de scripts et la liste d'autorisation, la garantie d'intégrité via la CSP et les hashes, la détection de falsification via le reporting et l'alerte, et des preuves exportables pour votre évaluation. Ce qu'il ne fait pas, c'est certifier votre conformité. Un évaluateur de sécurité qualifié (QSA), ou votre propre SAQ quand vous y êtes éligible, prend cette décision. Nous n'écrivons jamais « certifié PCI » ni « conformité garantie », parce que cette décision n'est pas la nôtre. La correspondance exacte entre chaque fonctionnalité et chaque sous-point d'exigence reste à confirmer sur votre propre déploiement, avec votre évaluateur, avant d'en faire état.

Une nuance à poser clairement : ces exigences concernent les scripts et les headers de votre page de paiement tels que le navigateur les voit. Un outil qui ne scanne que votre dépôt source ou votre configuration serveur ne satisfait pas 11.6.1, parce qu'il ne voit pas ce que le navigateur du consommateur a reçu. Les preuves doivent venir du côté navigateur.

Où s'inscrit Google Tag Manager

Si vous chargez Google Tag Manager sur votre page de paiement, il est dans le périmètre des deux exigences : GTM peut injecter des scripts, donc chaque tag qu'il charge est un script de page de paiement que vous devez inventorier, autoriser et surveiller pour changement. Un conteneur compromis est précisément le scénario que 11.6.1 doit détecter. Traitez les tags GTM comme des scripts dans le périmètre, pas comme une exception.

Mettez tout ensemble

CentralCSP ingère les rapports de violation et de hash CSP de votre page de paiement, construit l'inventaire de scripts, alerte sur les changements de scripts et de headers, et exporte les preuves dont votre évaluateur a besoin, ce qui est le côté surveillance de 6.4.3 et 11.6.1. Vous pouvez démarrer un essai gratuit, pointer un header Report-Only depuis vos pages de checkout vers lui, et regarder l'inventaire et les rapports se construire à partir du trafic réel avant de passer en application.

Foire aux questions

Que demande PCI DSS 6.4.3 ?

Que vous gériez les scripts de votre page de paiement : tenir un inventaire avec une justification écrite pour chacun, autoriser chaque script avant qu'il ne s'exécute, et avoir une méthode pour garantir l'intégrité de chaque script. Le but est qu'aucun script non approuvé ne s'exécute sur la page de paiement.

Que demande PCI DSS 11.6.1 ?

Un mécanisme de détection de changement et de falsification sur la page de paiement qui vous alerte de toute modification non autorisée des security headers HTTP et du contenu des scripts tels que reçus par le navigateur du consommateur, évalué au moins tous les sept jours ou selon une fréquence fixée par votre analyse de risque.

Une CSP satisfait-elle PCI DSS v4 à elle seule ?

Pas à elle seule. Une CSP impose quels scripts peuvent s'exécuter et appuie l'intégrité, ce qui aide pour 6.4.3. Répondre aux deux exigences demande aussi un inventaire avec justifications, une détection de changement et une alerte sur la page de paiement, plus les enregistrements à montrer à votre évaluateur. C'est le reporting côté navigateur qui fait que la preuve reflète ce que le consommateur a reçu.

CentralCSP certifie-t-il la conformité PCI DSS ?

Non. CentralCSP vous aide à répondre aux exigences côté client (6.4.3 et 11.6.1) en fournissant la surveillance, l'alerte et les preuves exportables. Un QSA, ou votre SAQ quand vous y êtes éligible, valide la conformité.

À retenir

PCI DSS v4 6.4.3 et 11.6.1 sont des exigences côté navigateur : connaître et autoriser les scripts de votre page de paiement, et détecter quand un script ou un header change. Une CSP stricte impose l'autorisation et appuie l'intégrité, un inventaire de scripts vous donne la liste autorisée, et le reporting des violations avec l'alerte sur changement vous donne la détection de falsification, le tout à partir de ce que le navigateur du consommateur a réellement chargé. Cet ensemble de contrôles et d'enregistrements est la façon de répondre aux exigences ; c'est votre évaluateur qui valide.

Pour aller plus loin : la bibliothèque de documents du PCI Security Standards Council pour le standard et les guides associés.