Scripts tiers sur la page de paiement : ce qu'exige le PCI DSS

Chaque script exécuté sur la page de paiement (chat, mesure d'audience, gestionnaire de balises, avis clients, pixels marketing) peut, en principe, voir ce que saisit le client. C'est pourquoi le PCI DSS exige, avec l'exigence 6.4.3, un inventaire de tous ces scripts avec leur justification, une méthode pour autoriser chacun et une autre pour s'assurer qu'ils n'ont pas été modifiés ; et, avec l'exigence 11.6.1, un mécanisme qui détecte les changements de la page telle que le client la reçoit et alerte l'équipe, au moins une fois par semaine. Les deux règles sont obligatoires depuis le 31 mars 2025.

Pourquoi les scripts tiers sont le maillon faible

Un script tiers n'est pas hébergé chez vous : le navigateur du client va le chercher sur le serveur du fournisseur à chaque visite. Si ce fournisseur est piraté ou modifie le fichier, votre page change aussi, sans que votre équipe ait rien publié. Le guide du PCI Security Standards Council sur la sécurité des pages de paiement, publié en mars 2025, rappelle aussi que ces scripts peuvent en charger d'autres, venant des partenaires du partenaire, et cite les outils de mesure d'audience, de marketing, de gestion de balises, de validation de formulaires et même de paiement parmi ceux qui peuvent être détournés pour capturer des données.

Une étude de cas de Visa illustre l'effet démultiplicateur. L'enquête a commencé par le signalement d'une banque concernant un seul restaurant, mais le code malveillant se trouvait dans un fichier légitime hébergé par le prestataire de commande en ligne, pas sur le site du restaurant. Ce même fichier était utilisé par une grande partie des plus de 1 500 clients du prestataire, et un tiers d'entre eux ont été compromis. Visa a remonté jusqu'à la source dix jours après l'infection.

Ce que demande le PCI DSS, en clair

Exigence 6.4.3 : inventaire, autorisation et intégrité

Chaque script chargé et exécuté dans le navigateur du client sur la page de paiement doit répondre à trois conditions :

• Autorisation : une méthode pour confirmer que chaque script a été approuvé. La norme ne précise ni comment ni par qui ; selon le guide du PCI SSC, l'approbation peut intervenir avant l'ajout ou la modification, ou dès que possible après, puisque le fournisseur peut changer le fichier sans prévenir.
• Intégrité : une méthode pour garantir que le script ne contient rien de non autorisé, à son introduction comme à chaque mise à jour.
• Inventaire : la liste de tous les scripts, avec une justification métier ou technique pour chacun. Dans un environnement simple, précise le guide, un tableur peut suffire.

Les scripts d'authentification 3-D Secure sont dispensés de cette validation. Et un fournisseur dont les scripts n'ont rien à voir avec le paiement peut ne pas être considéré comme prestataire de services pour d'autres volets de la norme, mais ses scripts restent soumis aux exigences 6.4.3 et 11.6.1.

Exigence 11.6.1 : détecter les changements

Il faut un mécanisme qui alerte l'équipe en cas de modification non autorisée (scripts qui apparaissent, changent ou disparaissent, et changements des en-têtes de sécurité) sur la page telle que le navigateur du client la reçoit. Il doit fonctionner au moins chaque semaine ou à une fréquence fixée par une analyse de risques ciblée. Le PCI SSC recommande lui-même une surveillance fréquente, voire en temps réel, lorsque c'est possible, car une modification malveillante peut agir sans être vue entre deux contrôles.

Construire l'inventaire en pratique

1. Cartographiez les pages. Incluez celle qui affiche le formulaire du prestataire de paiement. Sur les sites à page unique, où le navigateur ne recharge pas entre les étapes, les scripts chargés plus tôt restent actifs au paiement, et le guide considère toutes les vues comme concernées.
2. Listez ce que reçoit le navigateur, pas seulement ce qui figure dans votre code : ouvrez la page comme un client, car les gestionnaires de balises ajoutent des scripts à la volée.
3. Documentez chaque script : adresse d'origine, fournisseur, responsable interne, finalité, justification, qui l'a approuvé et quand.
4. Tranchez : il reste, il part ou il change de page. Pas de justification, pas de script.
5. Choisissez comment garantir l'intégrité : liste des provenances autorisées, vérification de l'empreinte du fichier ou outil spécialisé. Le PCI DSS n'impose pas de méthode.
6. Consignez le comportement attendu : quels champs le script doit lire et où il envoie des données.
7. Revoyez à chaque changement, y compris ceux que le fournisseur fait de lui-même.

Ce qui peut mal tourner

• Le tableur vieillit. Un inventaire que personne ne met à jour devient une vieille photo de la page.
• Approuver le fournisseur, pas la version. Le fichier change sur son serveur, et l'ancienne approbation ne couvre pas le nouveau code.
• Oublier la page autour du formulaire. Utiliser le formulaire du prestataire réduit le périmètre, mais la page qui l'affiche reste sous votre responsabilité.
• Des alertes sans responsable. Si le mécanisme alerte sans bloquer, le PCI SSC insiste sur une réaction rapide ; décidez qui reçoit les alertes et qui agit.
• Prendre le minimum pour l'objectif. Un contrôle hebdomadaire laisse des jours d'exposition.

Proteside produit cette preuve tout en protégeant : il enregistre les scripts autorisés sur la page de paiement, vérifie dans le navigateur de l'acheteur ce qui change et où partent les données, et bloque ce qui ne devrait pas s'y trouver. Découvrez la solution de conformité PCI DSS et la protection des paiements par carte, et essayez gratuitement pendant 14 jours.