En bref : liste de vérification pratique de conformité PCI DSS 6.4.3 pour scripts de paiement
- La plupart des équipes prennent Subresource Integrity comme la réponse à 6.4.3. Ce n'est pas suffisant à lui seul : SRI n'inventorie pas tous les scripts automatiquement, ne s'applique pas aux scripts chargés dynamiquement et ne détecte pas les changements de comportement d'un script autorisé, qui est le vecteur principal des attaques Magecart.
- 6.4.3 est obligatoire depuis le 31 mars 2025 et couvre les bundles first-party, balises tierces, pixels analytiques, widgets de chat et bibliothèques CDN. cside PCI Shield se déploie comme une unique balise de script sur la page de paiement, et la plupart des équipes bouclent l'intégration technique en moins de 30 minutes.
- Si votre checkout tourne avec quelques scripts statiques, SRI plus CSP peut tenir comme contrôles de base. Si un gestionnaire de balises injecte des scripts dynamiquement, ajoutez la surveillance d'intégrité au runtime, cside est validé par VikingCloud pour 6.4.3 et 11.6.1.
L'exigence 6.4.3 de PCI DSS 4.0.1 vous demande de faire trois choses pour chaque script qui s'exécute sur une page de paiement : confirmer qu'il est autorisé, conserver une justification écrite expliquant pourquoi il a sa place, et le protéger par un contrôle d'intégrité qui repère les changements non autorisés. Cette exigence est obligatoire depuis le 31 mars 2025, et elle couvre le code interne, les balises tierces, les pixels d'analytics, les widgets de chat et tout ce qui s'exécute dans le contexte d'une page de paiement.
Elle existe pour répondre au skimming des pages de paiement, ces attaques de type Magecart où un JavaScript malveillant est glissé dans une page de commande pour récolter les données de carte à mesure que les clients les saisissent. L'exigence 6.4.3 est l'un des deux nouveaux contrôles côté client de PCI DSS 4.0.1, et son pendant, la 11.6.1, gère le volet surveillance. Cette liste de contrôle détaille ce que demande la 6.4.3 et comment y parvenir.
Ce que l'exigence 6.4.3 impose réellement
Le PCI Security Standards Council définit trois contrôles précis dans le cadre de l'exigence 6.4.3 :
1. Une méthode pour confirmer que chaque script est autorisé. Il vous faut une autorisation documentée pour chaque script présent sur les pages de paiement. Cela vise non seulement les scripts écrits par votre équipe, mais aussi chaque balise tierce, pixel d'analytics, widget de chat, outil de test A/B et bibliothèque chargée depuis un CDN qui s'exécute dans le contexte d'une page de paiement. L'autorisation signifie que vous savez que le script est là et que vous avez une raison métier de l'y garder.
2. Une méthode pour garantir l'intégrité de chaque script. Chaque script doit être protégé contre toute modification non autorisée. Vous pouvez y parvenir avec des hachages Subresource Integrity (SRI) pour les scripts chargés depuis l'extérieur, des contrôles de Content Security Policy, ou un outil de surveillance à l'exécution qui alerte lorsque le contenu ou le comportement d'un script change. À elle seule, la SRI ne couvre pas les scripts chargés dynamiquement ni ceux servis par des CDN dont le contenu change sans que l'URL change.
3. Une justification écrite pour chaque script. Chaque script autorisé a besoin d'une raison métier documentée justifiant sa présence sur la page de paiement. Une balise qui n'est là que parce que le marketing l'a ajoutée il y a trois ans et que personne ne l'a retirée n'a aucune justification. Votre évaluateur vous réclamera cette documentation.
L'exigence associée, la 11.6.1, ajoute la détection des changements et des altérations : un mécanisme automatisé qui alerte lorsqu'un script de page de paiement ou un en-tête HTTP est modifié. Ensemble, la 6.4.3 et la 11.6.1 imposent à la fois un inventaire statique assorti de contrôles d'intégrité et une capacité de surveillance en direct.
Étape 1 : inventoriez chaque script de vos pages de paiement
Commencez par un audit complet de chaque script qui se charge sur la page de paiement. Cette liste comprend :
- Les scripts internes que votre équipe contrôle
- Les balises tierces chargées via des gestionnaires de balises (Google Tag Manager, Tealium, Segment)
- Les pixels d'analytics (Google Analytics, Meta Pixel, toute balise d'attribution marketing)
- Les widgets de chat et de support (Intercom, Drift, Zendesk)
- Les scripts de test A/B et de personnalisation
- Les outils de détection de fraude
- Toute bibliothèque chargée depuis un CDN
La plupart des équipes sont surprises du nombre de scripts qui s'exécutent réellement sur les pages de paiement. Les gestionnaires de balises sont le coupable habituel : ils chargent des scripts supplémentaires qui n'ont jamais fait l'objet d'une revue de sécurité. Un outil de surveillance qui découvre et répertorie chaque script présent est le moyen le plus rapide de constituer un inventaire fiable.
Étape 2 : autorisez et justifiez chaque script
Pour chaque script de l'inventaire, notez :
- Qui a autorisé le script sur cette page
- L'objectif métier qu'il remplit
- Si la page de paiement est le bon périmètre pour lui (de nombreux scripts d'analytics n'ont pas besoin de s'exécuter sur les pages de paiement et devraient en être exclus)
Tout script incapable de produire une justification métier claire devrait être retiré de la page de paiement. Moins de scripts, c'est une charge de conformité plus légère et une surface d'attaque plus réduite.
Étape 3 : mettez en place des contrôles d'intégrité
Pour chaque script autorisé, mettez en place un mécanisme d'intégrité. Vos options :
Subresource Integrity (SRI). Pour les scripts chargés depuis des URL externes, un hachage SRI dans la balise de script indique au navigateur de rejeter le script si son contenu a changé. La SRI fonctionne bien pour les scripts servis depuis des URL de CDN stables et versionnées. Elle n'aide pas pour les scripts chargés dynamiquement, les scripts dont le contenu change sans que l'URL change, ou les scripts en ligne.
Content Security Policy. Une liste d'autorisation CSP empêche les scripts non autorisés de se charger. Elle ne détecte pas les changements de comportement d'un script déjà présent sur la liste d'autorisation.
Surveillance de l'intégrité à l'exécution. Un outil qui observe le comportement des scripts en temps réel détecte le cas où un script autorisé se met à faire quelque chose de nouveau, comme lire un champ de formulaire qu'il n'avait jamais touché ou appeler un point de terminaison qu'il n'avait jamais appelé. Ce changement de comportement est le vecteur Magecart, et c'est justement celui que la SRI et la CSP manquent.
Pour une couverture complète de la 6.4.3 et de la 11.6.1, la surveillance à l'exécution est la couche qui fait le travail. La SRI et la CSP sont des contrôles fondamentaux qui viennent en dessous.
Comment cside satisfait à la fois à la 6.4.3 et à la 11.6.1
cside PCI Shield utilise une seule balise de script sur la page de paiement, puis :
- Découvre et inventorie chaque script présent, avec une mise à jour en continu
- Surveille le comportement de chaque script en temps réel et alerte lorsque ce comportement change
- Produit les preuves dont une évaluation PCI a besoin : un inventaire des scripts avec leur statut d'autorisation, plus des événements de détection d'altération horodatés
cside est validé par VikingCloud pour les exigences 6.4.3 et 11.6.1 de PCI DSS 4.0.1. Cette validation signifie qu'un évaluateur de sécurité qualifié a examiné l'outil et confirmé qu'il répond aux exigences de preuve précises des deux contrôles, et pas seulement à leur intention générale.
Pour aller plus loin
- cside PCI Shield : inventaire continu des scripts et surveillance à l'exécution pour les pages de paiement
- Pourquoi les crawlers ne peuvent pas aider à la conformité PCI (à eux seuls)
- Pourquoi la CSP ne fonctionne pas
- Vue d'ensemble de la conformité PCI DSS
