PCI DSS 6.4.3 et 11.6.1 expliquées : ce que vos pages de paiement doivent faire en 2026

Depuis le 1er avril 2025, toute évaluation PCI DSS v4.x inclut deux exigences qui n’existaient pas en v3.2.1 : 6.4.3 (gestion des scripts des pages de paiement) et 11.6.1 (détection de falsification des pages de paiement). Elles ont été écrites pour une menace précise : le skimming de type Magecart, où un seul script tiers compromis exfiltre silencieusement les données de carte depuis votre checkout.

Cet article explique ce que ces exigences disent réellement, la subtilité SAQ A que la plupart des marchands ratent et les moyens concrets de s’y conformer.

Ce qu’exige la 6.4.3

Tous les scripts chargés et exécutés dans le navigateur du consommateur sur les pages de paiement doivent être gérés ainsi :

• une méthode pour confirmer que chaque script est autorisé,
• une méthode pour garantir l’intégrité de chaque script,
• un inventaire de tous les scripts, avec une justification métier écrite pour chacun.

Trois verbes comptent : autoriser, garantir l’intégrité, inventorier. Un tableur mis à jour une fois par trimestre échoue sur les trois le jour où un tag manager injecte quelque chose de nouveau. Autre point de périmètre souvent raté : la « page de paiement » inclut la page parente qui intègre une iframe de paiement, et le périmètre ne s’arrête donc pas à l’iframe.

Ce qu’exige la 11.6.1

Un mécanisme de détection des changements et falsifications doit être déployé pour :

• alerter le personnel en cas de modification non autorisée (changements, ajouts, suppressions, indicateurs de compromission) des en-têtes HTTP et du contenu des pages de paiement tels que reçus par le navigateur du consommateur,
• être configuré pour évaluer les en-têtes HTTP et la page de paiement reçus,
• fonctionner au moins une fois tous les sept jours, ou à la fréquence fixée par votre analyse de risque ciblée (12.3.1).

L’expression clé : « tels que reçus par le navigateur du consommateur ». La surveillance d’intégrité côté serveur ne suffit pas, car un skimmer injecté via un CDN compromis ne touche jamais vos serveurs. Il faut observer ce que les navigateurs exécutent réellement.

Le piège du SAQ A

Début 2025, le PCI Council a retiré 6.4.3, 11.6.1 et 12.3.1 de la liste du SAQ A (marchands en iframe/redirection). Dans le même mouvement, il a ajouté un critère d’éligibilité : le marchand doit confirmer que tous les éléments de la page de paiement livrés au navigateur proviennent uniquement de prestataires conformes PCI et que « le site n’est pas exposé à des attaques par scripts » affectant le système e-commerce.

Les exigences n’ont pas disparu. Elles se sont déplacées dans la porte d’éligibilité. Si un script de la page parente de votre checkout peut altérer l’iframe de paiement, vous ne pouvez pas cocher la case honnêtement. La plupart des marchands SAQ A ont donc toujours besoin d’une surveillance des scripts et des en-têtes. Seule la forme de la preuve change.

Trois façons de se conformer

Première voie : les agents de sécurité client-side « entreprise » (Source Defense, Jscrambler, HUMAN Security, c/side). Un agent JavaScript observe ou isole chaque script dans le navigateur du visiteur. C’est la détection comportementale la plus poussée, mais regardez le prix d’entrée : vous ajoutez le script d’un fournisseur sur la page de paiement que ces exigences sont censées protéger, une exposition supply-chain de plus que votre assesseur voudra examiner. Les tarifs sont négociés en cycle commercial, souvent au page-view, donc la facture suit votre trafic plutôt que votre risque, et le déploiement mobilise vos équipes front.

Deuxième voie : le faire soi-même. Construire une allowlist de scripts, ajouter des hashes Subresource Integrity, lancer des contrôles hebdomadaires en navigateur synthétique, tenir l’inventaire dans un document. Faisable sur le papier. En pratique, l’inventaire se périme en silence dès qu’un tag manager pousse quelque chose que personne n’a noté, les contrôles d’intégrité ratent les scripts chargés dynamiquement, et l’assemblage des preuves d’audit devient un projet manuel récurrent qu’il faut bien confier à quelqu’un.

Troisième voie : la surveillance depuis le navigateur via CSP. L’en-tête Content-Security-Policy fait déjà remonter, par le navigateur de chaque visiteur, les scripts chargés sur vos pages de paiement. CentralCSP exploite ce signal (un seul en-tête HTTP, aucun agent sur la page) pour maintenir un inventaire de scripts vivant avec hashes d’intégrité (SHA-256/384/512) sur tous les plans, et, dans le module PCI DSS du plan Scale (349,99 €/mois), le reste de ce que les deux exigences réclament : vous déclarez vos pages de paiement, chaque script qui s’y charge reçoit une autorisation et une justification métier ou technique écrite, avec des règles d’auto-validation pour les rotations de hash de routine et la corrélation aux CVE connues via la vue Technologies (6.4.3), et une chronologie datée enregistre chaque script ajouté, modifié ou retiré, avec une alerte dès qu’un script apparaît sans justification et des exports de preuves en CSV, PDF et SBOM (11.6.1). Les règles s’évaluent à l’ingestion, bien au-delà du minimum de sept jours, et les justifications comme le registre des changements sont conservés jusqu’à la suppression du compte, pas seulement les 90 jours de vie des rapports bruts. Pour la plupart des marchands, c’est la voie que nous recommandons : les deux exigences couvertes depuis un seul en-tête, aucun script ajouté à la page de paiement, aucun cycle commercial à traverser.

L’acceptation des approches basées CSP pour la 11.6.1 varie selon les QSA : le dossier de preuves compte autant que le mécanisme. Un inventaire vivant, des justifications, des hashes et un journal de changements exportable valent mieux qu’une explication orale du fonctionnement de l’en-tête. C’est précisément le contenu des exports de preuves de CentralCSP : la question du QSA devient un exercice de documentation déjà fait, pas un débat de mécanismes. Ce que contient ce dossier, page par page, est détaillé dans prouver que vos scripts de paiement n’ont pas changé.

Par où commencer

Avant tout le reste, passez une page de paiement dans le scanner CSP gratuit. Une minute, sans compte, et son score de sécurité vous dit si vous partez d’un en-tête absent ou d’une politique qui demande juste à être resserrée (il note la politique, il ne note pas la conformité PCI, et la nuance mérite d’être comprise avant l’évaluation).

1. Listez vos pages de paiement, y compris celles qui intègrent des iframes de paiement.
2. Déployez-y un en-tête CSP en mode report-only. Rien ne peut casser dans ce mode.
3. Laissez le trafic réel alimenter l’inventaire de scripts pendant une à deux semaines.
4. Passez en revue, autorisez et justifiez chaque script, puis supprimez ce que personne ne peut justifier.
5. Déclarez ces pages comme pages de paiement dans le module PCI, activez l’alerte « script non justifié » et exportez votre premier dossier de preuves avant que l’auditeur ne le demande.

Les équipes qui souffrent avec 6.4.3 et 11.6.1 sont celles qui les traitent comme un exercice documentaire annuel. Le navigateur veut bien vous dire ce qui tourne sur votre checkout, chaque jour, pour chaque visiteur. Encore faut-il l’écouter, et CentralCSP est le chemin le plus court pour cette écoute : un en-tête pour l’inventaire, le module PCI du plan Scale pour les justifications, le registre des changements et les alertes, avec l’export de preuves prêt avant le début de l’évaluation.