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 les deux se poursuivent dans le standard actuel, 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 ces exigences s'appuient pour les preuves ; traitez la correspondance exacte entre fonctionnalité et exigence comme quelque chose à caler avec votre évaluateur, pas comme 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 chargés et exécutés là.

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

Lues ensemble, 6.4.3 porte sur le fait de connaître et d'autoriser ce qui doit être là, et 11.6.1 porte sur le fait 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 ce que donne une CSP plus le 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, plus une justification enregistrée par script, est la liste autorisée-et-inventoriée que demande 6.4.3. Une CSP stricte est le côté application : une politique à nonce plus 'strict-dynamic' fait que seuls les scripts que vous avez marqués s'exécutent, 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é pour 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, ce rapport arrive à 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é. Parce que les rapports viennent de vrais navigateurs chargeant la page, ils reflètent la page telle que le consommateur la reçoit, ce qui est exactement le point de vue que 11.6.1 nomme.

Un court exemple du câblage 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 risque est un workflow en soi ; 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 de chaque fonctionnalité à chaque sous-point d'exigence est quelque chose à confirmer face à votre propre déploiement et avec votre évaluateur avant de la citer.

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 le scénario précis que 11.6.1 est censé attraper. 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 d'appliquer.

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 applique quels scripts s'exécutent et soutient 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. Le reporting côté navigateur est ce 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 applique l'autorisation et soutient 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.