Les données de cartes se volaient dans les bases de données. Depuis bientôt dix ans, elles se volent dans le navigateur : quelques lignes de JavaScript ajoutées à la page où le client tape son numéro de carte, qui lisent les champs au fil de la saisie et les envoient ailleurs pendant que le vrai paiement passe sans encombre. Le serveur est propre. Les journaux sont propres. Le client ne voit rien. L’acquéreur voit un amas de fraude six semaines plus tard et remonte la piste.
PCI DSS v4 a répondu par deux exigences, 6.4.3 et 11.6.1, obligatoires depuis fin mars 2025. Elles sont courtes, précises, et on y répond régulièrement avec les mauvaises preuves. Voici ce que chacune demande, ce qui y satisfait, et ce qui a changé pour les commerçants qui pensaient qu’un iframe les sortait du débat.
Exigence 6.4.3 : connaître ses scripts, les autoriser, vérifier leur intégrité
L’exigence s’applique à chaque script chargé et exécuté dans le navigateur du consommateur sur une page de paiement, et elle demande trois choses. Un inventaire de ces scripts, chacun avec une justification métier ou technique écrite. Une méthode pour confirmer que chaque script est autorisé. Une méthode pour garantir l’intégrité de chaque script.
L’inventaire est l’endroit où la plupart des équipes découvrent ce que leur page est devenue. Le code maison, la bibliothèque du prestataire de paiement, l’analytique, la gestion du consentement, le chat, les tests A/B, le gestionnaire de balises et tout ce qu’il charge, qui change sans déploiement. L’inventaire doit inclure les enfants, pas seulement le gestionnaire de balises, et quelqu’un doit pouvoir dire pourquoi chacun est sur la page où la carte est saisie. « Le marketing l’a demandé » est une raison de le déplacer sur une autre page, pas une justification.
L’autorisation, c’est la gestion des changements appliquée à la page telle que servie : un script n’apparaît sur la page de paiement qu’après qu’on l’a approuvé, et la liste des sources approuvées est appliquée quelque part, pas seulement classée. Une Content Security Policy en mode bloquant est l’application habituelle : le navigateur refuse d’exécuter ce qui vient d’une source que la politique ne nomme pas. Une politique en mode « report-only » est un outil de surveillance, pas un contrôle d’autorisation, et les évaluateurs le diront.
L’intégrité est la partie difficile. Pour un fichier tiers statique, la Subresource Integrity fait l’affaire : la balise porte l’empreinte, le navigateur refuse un fichier qui ne correspond pas. La plupart des fournisseurs de paiement et d’analytique servent des fichiers qui changent sans préavis et ne peuvent pas porter d’empreinte fixe ; pour ceux-là, la méthode d’intégrité est une surveillance, ce qui nous amène à 11.6.1, ou une décision : ce script n’a rien à faire sur cette page.
Exigence 11.6.1 : détecter le changement, dans le navigateur, et le dire à quelqu’un
La seconde exigence demande un mécanisme de détection des changements et des altérations sur la page de paiement telle que le navigateur du consommateur la reçoit, couvrant les en-têtes HTTP qui touchent à la sécurité et le contenu des scripts. Il doit alerter le personnel en cas de modification non autorisée, ajouts et suppressions compris. Il doit s’exécuter au moins une fois tous les sept jours, ou à la fréquence que justifie votre analyse de risque ciblée.
Relisez deux fois « telle que reçue par le navigateur du consommateur ». La surveillance d’intégrité des fichiers sur votre serveur web regarde des fichiers sur disque. Les skimmers s’injectent par des tiers compromis, par les gestionnaires de balises, par un CDN, et par le serveur lui-même de façons qui laissent les fichiers sur disque intacts. Un mécanisme qui regarde le serveur ne voit pas la page que reçoit le client. C’est la mauvaise réponse la plus fréquente que nous voyons dans les dossiers de preuves.
Les mécanismes qui y répondent, chacun avec une limite à connaître :
- Le rapport de violations CSP vous dit quand le navigateur a bloqué un script venant d’une source non listée. Il ne vous dit pas quand un script autorisé a changé de contenu. Il couvre les ajouts, pas les altérations.
- La surveillance synthétique depuis l’extérieur récupère la page comme le ferait un navigateur, à intervalle régulier, et compare en-têtes et contenu des scripts au dernier état connu bon. Elle voit ce qu’un client verrait, depuis l’endroit où tourne la sonde. Elle ne voit pas un skimmer qui ne s’active que pour certains clients ou certaines régions, et c’est pourquoi les meilleurs services interrogent depuis plusieurs endroits et varient leurs empreintes.
- Les agents dans la page s’exécutent aux côtés de vos scripts dans les navigateurs de vrais clients et rapportent ce qui a été exécuté. Ils voient le plus et ajoutent un script de leur cru à la page, qui entre alors dans l’inventaire.
- La comparaison d’empreintes des scripts que vos propres serveurs livrent n’attrape que les altérations de votre côté.
La plupart des environnements ont besoin de deux d’entre eux. Tous ont besoin d’une personne qui reçoit l’alerte et d’une procédure qui dit quoi en faire, parce que l’exigence, c’est l’alerte et la réaction, pas le tableau de bord.
Un mécanisme qui regarde le serveur ne voit pas la page que reçoit le client.
Qui doit quoi
Si votre page contient le formulaire de paiement, les deux exigences sont entièrement à vous.
Si votre page intègre l’iframe du prestataire de paiement ou redirige vers sa page hébergée, le prestataire doit les deux exigences pour le contenu qu’il sert, et vous êtes responsable de la page autour : la page parente est la vôtre, les scripts qu’elle porte sont les vôtres, et un skimmer sur la page parente peut remplacer ou recouvrir l’iframe. Que le formulaire soit à quelqu’un d’autre ne fait pas de la page celle de quelqu’un d’autre.
Si vous êtes le prestataire, l’évaluateur du commerçant vous demandera la preuve que le contenu de l’iframe et les scripts que vous demandez aux commerçants d’inclure respectent 6.4.3 et 11.6.1. Votre Attestation of Compliance devrait le dire sans qu’on le demande.
SAQ A : ce que change la confirmation écrite, et ce qu’elle ne change pas
Les commerçants qui utilisent un iframe ou une redirection se valident avec le SAQ A, le questionnaire le plus court, et c’est là que le standard a bougé deux fois.
PCI DSS v4 a d’abord mis 6.4.3 et 11.6.1 dans le SAQ A, demandant aux petits commerçants de tenir des inventaires de scripts et une détection d’altération sur une page qu’ils n’avaient, pour l’essentiel, pas écrite. La révision v4.0.1 du SAQ A a retiré les deux exigences et les a remplacées par une condition d’éligibilité : le commerçant a confirmé que son site n’est pas exposé aux attaques par scripts susceptibles d’affecter son système e-commerce. Les orientations du Council ont ensuite donné deux façons d’y satisfaire. Le commerçant peut appliquer les techniques de 6.4.3 et 11.6.1 à sa propre page. Ou il peut obtenir de son prestataire de paiement une confirmation écrite que le formulaire intégré protège contre les attaques par scripts lorsqu’il est mis en œuvre selon les instructions du prestataire.
La plupart des commerçants prendront la lettre, et c’est permis. Deux choses méritent d’être dites clairement.
La lettre change le questionnaire que vous remplissez. Elle ne change pas votre surface d’attaque. Trois petites boutiques que nous avons aidées après coup tournaient sur la même plateforme open source avec un iframe ou une redirection vers leur prestataire, chacune donc légitimement en SAQ A, et chacune a été compromise quand même : identifiants d’administration volés, module piégé, puis skimmers sur les pages que les commerçants possédaient. Les prestataires ont suspendu les paiements jusqu’à recevoir un scan conforme et un questionnaire signé par un QSA. La lettre aurait été parfaitement valable tout du long. Nous racontons cette histoire en entier dans Quand votre prestataire de paiement vous coupe.
La lettre contient une condition. « Lorsqu’il est mis en œuvre selon les instructions du prestataire » signifie que le guide d’intégration du prestataire fait désormais partie de vos preuves de conformité : l’iframe chargé comme le guide le dit, aucun de vos scripts qui y pénètre, la bibliothèque du prestataire chargée depuis la source du prestataire. Un évaluateur qui lit la lettre demandera à voir l’implémentation à côté des instructions. Gardez les deux.
Ce que l’on fait de travers
On surveille le serveur. L’exigence porte sur la page dans le navigateur.
On fait tourner une politique en « report-only » pendant un an et on appelle cela un contrôle. Le mode rapport observe ; le mode bloquant autorise.
On inventorie le gestionnaire de balises et pas ses enfants. Les enfants sont les scripts ; le gestionnaire est la façon dont ils sont arrivés là.
On lit « tous les sept jours » comme un scan hebdomadaire. Les sept jours sont un plafond, et l’analyse de risque qui justifie un intervalle plus long doit exister par écrit.
On prend l’iframe pour une frontière. Le contenu de l’iframe est au prestataire. La page est à vous, et c’est la page qui est attaquée.
On envoie les alertes vers une boîte que personne ne lit. Le mécanisme est complet quand une personne agit dessus.