Existe-t-il une méthode « gratuite » pour se conformer aux exigences PCI DSS 6.4.3 et 11.6.1 ?

PCI DSS 6.4.3 et 11.6.1 concernent le côté client, et la plupart des organisations n'ont jamais eu à les traiter avec ce niveau d'exigence auparavant.

Peut-on donc atteindre la conformité PCI pour ces deux exigences sans solution payante ? La réponse est : Non, en quelque sorte. Mais vous dépenseriez bien plus en salaires que ce que vous coûterait une solution commerciale.

Gardez cette phrase importante en tête tout au long de cet article. Elle a été ajoutée dans la mise à jour de janvier concernant les exigences 6.4.3 et 11.6.1.

« Pour que les commerçants puissent se qualifier pour le SAQ A, ils doivent confirmer que leur site n'est pas vulnérable aux attaques par scripts susceptibles d'affecter le ou les systèmes de commerce électronique du commerçant ».

Pourquoi ces exigences ont été établies

Depuis l'introduction de JavaScript dans les navigateurs en 2011, l'exécution côté client a ouvert la voie à des attaques de skimming de cartes à grande échelle. Des acteurs sophistiqués injectent désormais des scripts malveillants via des dépendances, des plugins ou des compromissions de la chaîne d'approvisionnement, menaçant la sécurité des données de paiement. Le plus souvent, ils exfiltrent les données de paiement de manière dynamique, en ne ciblant qu'un faible pourcentage d'utilisateurs pour rester sous le radar.

Visa, Mastercard et Amex ont tous désigné les attaques par scripts côté client comme la principale source de vol de données de cartes bancaires. La tokenisation aide, mais seulement dans une certaine mesure. Si le client est compromis, l'attaque réussit quand même.

PCI DSS v4.0 impose donc à juste titre aux entreprises de mettre en place des contrôles pour :

• Empêcher l'exécution de scripts non autorisés (6.4.3)
• Garantir l'intégrité des scripts (6.4.3)
• Maintenir un inventaire à jour des scripts avec leurs justifications métier (6.4.3)
• Détecter toute falsification ou modification non autorisée des pages de paiement (11.6.1)

Comment atteindre la conformité PCI DSS sans acheter de solution

Si vous êtes ingénieux, techniquement compétent et prêt à maintenir les outils vous-même, voici comment procéder.

1. Empêcher les scripts non autorisés (6.4.3)

Pour satisfaire l'exigence de n'autoriser que les scripts approuvés à se charger et s'exécuter, vous avez besoin d'une couche d'application robuste. Une Content Security Policy (CSP) peut remplir ce rôle, mais elle doit être configurée de manière stricte et maintenue activement.

Ce que vous pouvez faire :

• Déployer un en-tête CSP strict en utilisant script-src pour mettre en liste blanche les domaines autorisés.
• Utiliser des nonces ou des hashes pour autoriser explicitement les scripts inline ou dynamiques.
• Auditer régulièrement votre politique et la mettre à jour à chaque modification de script.

Est-ce suffisant pour PCI ? Oui, MAIS uniquement sur le plan formel. Les scripts dynamiques ne peuvent PAS être entièrement protégés par un CSP.

Le CSP est reconnu comme un contrôle valide pour autoriser les scripts. Cependant, le CSP seul ne suit pas l'intention. Vous avez besoin d'une documentation justifiant pourquoi chaque source autorisée l'a été.

MAIS, rappelez-vous la phrase citée plus haut :

« Pour que les commerçants puissent se qualifier pour le SAQ A, ils doivent confirmer que leur site n'est pas vulnérable aux attaques par scripts susceptibles d'affecter le ou les systèmes de commerce électronique du commerçant ».

Le CSP résout-il ce problème dans ce contexte ? NON. Si une source reste identique mais que le contenu du script livré change, un CSP ne le détecterait PAS.

L'attaque Polyfill de 2024 n'aurait PAS été stoppée par un CSP. Cela signifie techniquement que votre site EST vulnérable aux attaques, et que vous avez donc besoin d'un outil de sécurité pour être pleinement conforme. Vous pouvez vous inscrire ou réserver une démo pour en discuter avec nous.

Intégrez les points suivants à votre checklist de conformité PCI :

• Utiliser un CSP avec des restrictions script-src et des nonces/hashes.
• Le CSP doit être mis à jour et audité régulièrement.
• Gérer le CSP avec soin ; il est fragile et peut casser des applications.

2. Vérifier l'intégrité des scripts (6.4.3)

Vous devez être en mesure de détecter lorsqu'un script a été falsifié. Pour les scripts statiques, la Subresource Integrity (SRI) est une solution standard. Elle vérifie que seuls les scripts correspondant au hash attendu se chargent correctement.

Ce que vous pouvez faire :

• Ajouter les attributs integrity et crossorigin à chaque balise <script> tierce.
• Récupérer périodiquement les scripts, les hacher et comparer avec les hashes de référence connus.

Est-ce suffisant pour PCI ? Oui, MAIS uniquement pour les scripts statiques. Les scripts dynamiques ne peuvent PAS être couverts par le SRI seul.

Les scripts dynamiques (par exemple les outils d'analytics, les moteurs de tests A/B) changent souvent à chaque requête et rendront le SRI inopérant. PCI attend de vous que vous reconnaissiez cette limitation et la mitiguiez, soit en évitant les scripts dynamiques, soit en mettant en place un mécanisme de surveillance.

Comment surveiller ces scripts ? C'est impossible sans outillage. Soit une solution payante (comme cside 👋) — soit votre propre solution développée en interne.

Sans entrer dans les détails, voici comment vous pourriez construire votre propre outil de surveillance :

1. Créer une liste des URL de scripts dynamiques
2. Récupérer le contenu des scripts
3. Normaliser le payload — Supprimer les horodatages, les cache-busters ou les en-têtes de tracking CDN (si nécessaire).
4. Sauvegarder une version nettoyée du contenu pour comparaison.

Hacher ou comparer le résultat

1. En cas de changement : journaliser et alerter.

Alerter sur les changements inattendus

1. Envoyer un e-mail par exemple.

Documenter votre processus

1. PCI exige des preuves que vous surveillez activement l'intégrité des scripts.
2. Conserver les journaux de ces vérifications et des actions qui en découlent.

Mais est-ce vraiment réalisable en pratique ?

Développeriez-vous votre propre logiciel antivirus, par exemple ? Pour la plupart d'entre nous, la réponse est clairement « non ». Construire un moteur capable de détecter des comportements malveillants dans du JS est une tâche ardue qui nécessitera un jeu de données conséquent pour être efficace. Ce n'est pas seulement une question de temps passé. C'est aussi une question de ressources.

Points clés :

• Le SRI ne fonctionne que pour les scripts statiques. Utilisez-le partout où c'est possible.
• Le SRI ne fonctionne PAS avec les scripts dont le payload varie.
• La surveillance du contenu réel des scripts nécessite un outillage dédié.

3. Maintenir un inventaire des scripts (6.4.3)

Vous devez maintenir un inventaire de tous les scripts qui s'exécutent sur la page de paiement. Cela inclut les scripts statiques et dynamiques, les scripts inline, les sources tierces (comme les gestionnaires de tags ou les outils d'analytics), et tout ce qui est chargé via des frameworks (comme React ou Vue). PCI exige que chaque script ait été examiné, approuvé et justifié sur le plan métier ou technique. Et ce, tous les 7 jours (sur une base hebdomadaire).

Ce que vous pouvez faire :

• Créer une liste versionnée (tableur ou fichier YAML/JSON).
• Y inclure : la source du script, le hash attendu (si statique), la justification métier/technique, le propriétaire/l'équipe responsable.
• La mettre à jour à chaque déploiement ou modification de code (et non de code de script) affectant la page de paiement.

Voici ce que vous devez inclure :

• La source ou l'URL
• S'il est statique ou dynamique
• Un hash (si statique et SRI utilisé)
• La justification métier/technique
• Le propriétaire ou l'équipe responsable
• Des notes sur la surveillance (en particulier pour les scripts dynamiques)

Est-ce suffisant pour PCI ? Oui, PCI n'exige rien de plus à ce niveau. Une liste manuelle est acceptable à condition d'être précise et maintenue à jour. Les scripts dynamiques doivent tout de même être répertoriés, même si vous ne pouvez pas les hacher. Dans ces cas, PCI attend de vous que vous expliquiez pourquoi le SRI ne peut pas être utilisé et comment le script est surveillé à la place. REMARQUE : Cela ne signifie PAS que vous pouvez vous contenter de créer un inventaire sans agir sur les points ci-dessus. C'est une exigence formulée de manière légèrement plus souple que certains considèrent comme la solution miracle. Ce n'en est pas une.

4. Détection de falsification et de modification (11.6.1)

PCI exige que vous détectiez les modifications non autorisées de la page de paiement telle que reçue dans le navigateur de l'utilisateur. Cela inclut les modifications du contenu et des en-têtes HTTP (comme CSP, CORS, etc.).

Ce que vous pouvez faire :

• Utiliser un navigateur headless (par exemple Puppeteer) ou curl pour récupérer la page de paiement en production. Cela aura un coût...
• Capturer les en-têtes et le contenu HTML.
• Comparer avec une référence connue et alerter en cas de changement.
• Normaliser la sortie si nécessaire pour éviter les faux positifs (particulièrement important pour le contenu dynamique).
• Documenter quels changements déclenchent des alertes, qui intervient et comment.

Est-ce suffisant pour PCI ? Oui, À CONDITION de l'exécuter régulièrement et d'avoir documenté quels changements déclenchent des alertes, qui est notifié et quel est votre plan de réponse. La fréquence requise est hebdomadaire, SAUF justification contraire par une analyse de risque.

Note sur les pages dynamiques : Les frameworks à rendu côté client (React, Vue, etc.) chargent ou modifient souvent le DOM après le chargement de la page. Si vous n'en tenez pas compte, votre surveillance générera des faux positifs. Pour PCI, c'est en principe acceptable, À CONDITION de définir clairement ce que vous vérifiez (par exemple, l'en-tête CSP, les domaines de scripts externes, les sélecteurs DOM clés) et pourquoi. Si vous subissez malgré tout une attaque, gardez à l'esprit la phrase importante : « Pour que les commerçants puissent se qualifier pour le SAQ A, ils doivent confirmer que leur site n'est pas vulnérable aux attaques par scripts susceptibles d'affecter le ou les systèmes de commerce électronique du commerçant ».

Points clés :

• Utiliser curl ou un navigateur headless pour capturer et comparer les en-têtes et le HTML.
• Normaliser le contenu dynamique pour réduire les faux positifs.
• Effectuer les vérifications chaque semaine (ou plus fréquemment selon le niveau de risque).
• Mettre en place des alertes et un processus de réponse documenté.

Alors, peut-on le faire « gratuitement » ?

Oui, en quelque sorte. Mais c'est pratiquement impossible.

C'est techniquement faisable, mais fragile en pratique ET en termes de compatibilité. Surtout, vous dépenserez très probablement plus d'argent, de temps et de ressources qu'en optant pour une solution payante.

Vous devriez :

• Écrire vos propres outils ou scripts
• Développer votre propre méthode d'analyse des scripts — ce qui est coûteux et, en tant qu'entreprise non spécialisée en sécurité, vous n'auriez probablement pas accès aux données ni aux compétences nécessaires. Construiriez-vous votre propre antivirus ?
• Surveiller manuellement l'intégrité des scripts
• Maintenir un inventaire des scripts avec rigueur
• Normaliser et comparer des pages dynamiques sans vous noyer dans les faux positifs

Et surtout : Vous devez prouver que votre site n'est pas vulnérable aux attaques côté client, comme l'exige explicitement la mise à jour PCI DSS de janvier.

Un CSP ne stoppera pas les attaques sur la chaîne d'approvisionnement. Le SRI n'est pas compatible avec les scripts dynamiques. Et une simple vérification curl ne protégera pas contre une exfiltration sélective et contextuelle.

Si vous optez pour la voie DIY : Documentez tout, automatisez ce que vous pouvez, et préparez-vous à une charge de travail importante. Et développez vos propres outils, si possible. Mais surtout, calculez votre temps et vos ressources (humaines ou autres) et faites les comptes. Il y a de fortes chances que vous soyez mieux servi par une solution payante.

Si vous souhaitez être pleinement conforme et en sécurité, nous avons conçu cside exactement pour cela. Vous pouvez réserver une démo ici ou vous inscrire pour être conforme dès aujourd'hui.