Le PCI SSC met à jour le SAQ A pour PCI DSS 4.0.1 – Ce que vous devez savoir
Le 30 janvier 2025, le PCI SSC (Payment Card Industry Security Standards Council) a publié une mise à jour du Self-Assessment Questionnaire A (SAQ A) pour le PCI DSS (Payment Card Industry Data Security Standard) v4.0.1.
Le communiqué indique que suite aux retours des parties prenantes, les exigences 6.4.3 et 11.6.1 sont désormais supprimées du SAQ A. En contrepartie, pour être éligibles au SAQ A, les commerçants 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».
Ce questionnaire s'applique aux commerçants qui externalisent entièrement le traitement des paiements à des prestataires tiers et ne manipulent ni ne stockent eux-mêmes les données de paiement.
Toutefois, l'introduction de la nouvelle exigence d'auto-attestation suscite des inquiétudes, car de nombreuses entreprises ne disposent pas de l'expertise nécessaire pour évaluer précisément leur exposition aux attaques côté client. Ces changements créent de nouveaux défis en matière de conformité, notamment concernant les risques de sécurité côté client, laissant les commerçants dans l'incertitude quant à leur éligibilité et à leurs responsabilités au titre du SAQ A.
En tant qu'entreprise spécialisée dans la sécurité côté client, nous aidons nos clients à se conformer aux deux exigences, et cet article vise à clarifier les implications de cette mise à jour.
Nouvelles responsabilités pour les commerçants SAQ A
Le PCI SSC a élaboré ces Self-Assessment Questionnaires (SAQs) pour examiner les obligations de conformité des commerçants. Il appartient aux commerçants d'évaluer s'ils satisfont aux exigences décrites dans le questionnaire.
Le SAQ A, conçu pour les commerçants les moins exposés, les exempte de certaines exigences PCI DSS dans la mesure où ils ne stockent pas de données de titulaires de carte (CHD).
Avec cette révision, les exigences 6.4.3 et 11.6.1 ne s'appliquent plus aux commerçants SAQ A.
Cependant, une nouvelle exigence du SAQ A impose aux commerçants de s'auto-attester 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 ».
Or, de nombreux commerçants ne disposent pas de l'expertise technique nécessaire pour évaluer avec précision s'ils sont exposés aux attaques côté client.
Étant donné que 98,9 % des sites web utilisent actuellement du JavaScript côté client, cette nouvelle exigence pourrait rendre de nombreux commerçants inéligibles au SAQ A.
Un besoin de clarté accru
Le PCI SSC propose une gamme de Self-Assessment Questionnaires. Pourtant, le document « SAQ Instructions and Guidelines » n'a pas encore été mis à jour pour tenir compte de ces changements.
Compte tenu de l'évolution significative du périmètre, nous estimons qu'une mise à jour est nécessaire pour que les commerçants comprennent pleinement leurs obligations de conformité.
Qu'est-ce que le SAQ A et comment y répondre
Selon le PCI SSC :
« Les commerçants SAQ A peuvent être des commerçants en ligne ou par courrier/téléphone (carte absente), et ne stockent, ne traitent ni ne transmettent aucune donnée de titulaire de carte sous forme électronique sur leurs systèmes ou leurs locaux. »
À noter que les critères d'éligibilité mis à jour pour le SAQ A ont été modifiés comme suit : « commerçants dont les fonctions liées aux données de compte sont entièrement externalisées à des tiers validés et conformes PCI DSS, où le commerçant ne conserve que des rapports papier ou des reçus contenant des données de compte. »
Et désormais, le commerçant doit également : « confirmer que son site n'est pas vulnérable aux attaques par scripts susceptibles d'affecter le ou les systèmes de commerce électronique du commerçant. »
Si un commerçant s'appuie sur la page web d'un prestataire externe pour traiter les paiements, il n'a aucun contrôle sur l'éventualité d'une attaque par script côté client sur la page de paiement du tiers. La surveillance relève de la responsabilité du prestataire de paiement.
Concernant le second groupe, les déclarations relatives aux iframes sont vagues et induisent en erreur. Lorsqu'on utilise une iframe, il est pratiquement impossible d'éliminer totalement le risque d'attaques côté client.
Pour confirmer que le site d'un commerçant n'est pas vulnérable aux attaques côté client, examinons dans quelles circonstances ces attaques se produisent et ce qui est considéré comme une attaque côté client.
La documentation du PCI SSC a cessé d'utiliser le terme « skimming », jugé trop vague et sujet à interprétation, au profit d'un terme plus technique : « attaques côté client » ou « attaques par scripts ».
Nous définissons les « attaques côté client » ou « attaques par scripts » comme toute méthode utilisée par un acteur malveillant pour capturer les informations de carte de paiement d'un utilisateur directement depuis son navigateur.
Comment se produisent les attaques côté client
Il existe 3 catégories de pages de paiement numérique :
- Pages de paiement par redirection : lors du paiement, le visiteur est redirigé vers le domaine distinct d'un prestataire de paiement pour saisir ses informations de carte. Une fois la transaction effectuée, il est renvoyé sur le site du commerçant.
- Un formulaire de paiement intégré : les informations de paiement sont collectées via une iframe ou un widget, intégrant un « mini-navigateur » tiers dans le site du commerçant pour afficher le formulaire du prestataire de paiement.
- Un formulaire conçu et géré par le commerçant : le formulaire de paiement est conçu et géré par le commerçant, qui transmet les informations de paiement au processeur via une API.
Chaque catégorie présente ses propres implications en matière de sécurité, et il est essentiel de comprendre où et quels risques côté client s'appliquent pour assurer la conformité.
Risques de sécurité pour les pages de redirection
Les pages de redirection peuvent sembler sécurisées, mais les commerçants n'ont aucun contrôle sur la page de paiement. Si un script malveillant est injecté, des attaquants peuvent détourner le processus de redirection, envoyant les clients vers une fausse page de paiement identique à l'originale et volant leurs informations de paiement au passage. Même en faisant appel à un prestataire tiers de confiance pour le paiement, les risques côté client demeurent. Des scripts malveillants peuvent modifier les fonctions de clic, altérant le parcours de paiement sans être détectés. Recourir à un prestataire de paiement tiers n'élimine pas le risque d'attaque côté client ; cela expose simplement les sites des commerçants à une variante légèrement différente de ces attaques.
Démonstration d'attaque : comment une page de paiement peut être manipulée
Imaginez que vous faites des achats en ligne et que vous cliquez sur le bouton « Payer maintenant » ci-dessous.
.pay-button:active { background-color: #166534; }
Pay NowEn voyant cette page, auriez-vous remarqué quelque chose d'anormal ?
Cette page a été créée en 5 minutes. Bien que vous ne puissiez pas réellement saisir vos données de paiement sur cette page de démonstration, avec deux minutes de travail supplémentaires, je pourrais capturer toutes les données que vous saisissez dans ce champ de paiement et les utiliser pour payer le vrai commerçant. Cela signifie que vous recevriez votre confirmation de commande et que tout se passerait normalement, tandis que les informations de carte de crédit seraient simultanément volées.
Les attaquants peuvent même insérer dynamiquement le logo du commerçant, rendant la fausse page identique au site original. Pour rendre l'attaque encore plus discrète, ils peuvent ne rediriger qu'un certain pourcentage des clients finaux, à une heure précise de la journée, dans certaines régions du monde, ou même en évitant les adresses IP du commerçant — ce qui permet à l'attaque de passer inaperçue pendant une longue période.
En détournant l'appui sur le bouton qui redirige l'utilisateur vers la page de paiement, le processeur de paiement n'aurait pas pu empêcher l'attaque. Dans cet exemple, le commerçant était le seul acteur en mesure d'agir pour prévenir l'attaque.
Risques de sécurité pour les formulaires de paiement intégrés
Si votre activité relève de la catégorie 2, c'est-à-dire que vous intégrez une iframe dans votre site pour afficher le formulaire d'un prestataire de paiement tiers, votre processus de paiement reste vulnérable aux attaques côté client.
Un script malveillant peut très facilement intercepter les données du titulaire de carte de plusieurs façons :
- En affichant une autre iframe par-dessus celle du vrai prestataire de paiement.
- En masquant la vraie iframe et en la remplaçant par une fausse saisie.
- Et par diverses autres méthodes d'attaque permettant de capturer des informations sensibles sans être détecté.
Tout JavaScript malveillant présent sur le site d'un commerçant aurait toute latitude sur la page et pourrait exécuter ces attaques. La seule façon d'éliminer totalement ce risque serait de supprimer tout JavaScript de la page de paiement ou d'implémenter des en-têtes CSP très stricts et des directives SRI — ce qui est rarement faisable, car la plupart des prestataires de paiement (et des outils critiques courants tels que les chatbots, les outils d'analyse web, les rapports d'erreurs, etc.) nécessitent du JavaScript dynamique côté client pour fonctionner correctement.
Maintenir ces contrôles tout en garantissant le bon fonctionnement en production représente un défi considérable, en particulier lors de l'utilisation de frameworks et de plateformes tels que React, Vue, Magento, Drupal, WooCommerce, etc. Atteindre ce niveau de sécurité manuellement sans acquérir une solution dédiée est pratiquement impossible sans un effort colossal aux conséquences potentiellement désastreuses.
Risques de sécurité pour les formulaires conçus et gérés par les commerçants
Si votre activité relève de la catégorie 3, c'est-à-dire que vous avez développé votre propre composant de paiement, votre processus de paiement est encore plus vulnérable. Ces formulaires de paiement gérés par le commerçant présentent les mêmes risques de détournement que les iframes intégrées — et davantage encore — car d'autres scripts s'exécutant sur le site peuvent enregistrer les données de paiement par keylogging.
Comment les attaques côté client sont-elles injectées ?
Les frameworks web modernes
Les frameworks modernes d'applications web monopages, tels que React, sont devenus la norme. Ces frameworks génèrent des « applications web monopages » car ils s'appuient sur du JavaScript côté client pour mettre à jour dynamiquement la page web, permettant un chargement plus rapide et une navigation fluide entre les pages.
Cependant, le principe même de ces frameworks est qu'ils ne rechargent pas la page. Par conséquent, les scripts ajoutés à une partie spécifique du site peuvent s'exécuter sur n'importe quelle page, à moins qu'un rechargement complet ne soit déclenché avant la navigation. Cela introduit des risques de sécurité, car des scripts malveillants peuvent rester actifs lorsque l'utilisateur navigue vers des pages où ces scripts n'étaient pas censés être présents.
En conséquence, la focalisation de la spécification originale sur les « scripts sur la page de paiement » devient inefficace pour les applications monopages, qui constituent pourtant l'approche la plus répandue du développement web depuis de nombreuses années.
De plus, les développeurs utilisant des stacks modernes s'appuient sur des dépendances open source provenant de NPM. C'est tout à fait logique, car les sites web remplissent des fonctions similaires et tout réécrire from scratch reviendrait à réinventer la roue. L'utilisation de bibliothèques préconstruites accélère considérablement le développement web.
Ce que beaucoup ignorent, c'est que les scripts NPM peuvent facilement injecter des charges utiles récupérées côté client. Les outils de sécurité axés sur les menaces de la chaîne d'approvisionnement NPM peinent à détecter efficacement ces injections car ils manquent de visibilité sur l'activité côté client, en particulier en temps réel et de manière exhaustive.
Cet excellent article viral sur Medium de 2018 illustre cette méthode de façon assez amusante.
Les outils tiers
Une autre méthode d'injection courante consiste à détourner un script ou outil tiers ajouté au site web. Il peut s'agir d'outils d'analyse, de publicité, de tests A/B, de widgets, de scripts de suivi pour les réseaux sociaux… Ces scripts comportent souvent un arbre de dépendances intégrant de nombreux outils open source.
L'attaque polyfill de juin 2024 en est un exemple majeur, utilisé dans la nature. Ce type d'attaque n'est vraiment pas difficile à réaliser. Les attaquants peuvent détourner un bucket S3, prendre le contrôle d'un domaine expiré intégré dans des sites web, revendiquer une URL S3 abandonnée ou rejoindre un projet open source et injecter discrètement une dépendance tierce… les possibilités sont infinies.
Les injections via les plateformes legacy
Même si vous utilisez une plateforme de commerce legacy, souvent basée sur PHP, il a été démontré au fil du temps que celles-ci sont très vulnérables aux injections côté client via des CVE courants.
Le terme « Magecart », expression historique désignant les attaques côté client, est né des injections côté client dans Magento pour exfiltrer les données des titulaires de carte. Pourtant, cette menace dépasse largement Magento. Rien qu'en janvier 2025, nous avons détecté plus de 15 000 sites web touchés par de nouvelles attaques côté client WordPress, soulignant le risque croissant sur toutes les plateformes.
Dans ce contexte, il est important de rappeler que JavaScript est utilisé comme langage de programmation côté client par 98,9 % de tous les sites web, ce qui en fait une cible de choix pour les attaquants.
Par conséquent, sans sécurité côté client, il est impossible d'écarter avec certitude une attaque ou de prétendre y être immunisé.
Surveillance côté client en temps réel pour la sécurité des sites web
La méthode la plus efficace pour sécuriser votre site web et maintenir la conformité PCI DSS consiste à surveiller l'intégralité du côté client à l'aide d'un outil de surveillance actif et en temps réel. Cette approche va au-delà des méthodes traditionnelles telles que l'exploration ponctuelle, la revue manuelle des scripts sur une page de paiement ou la vérification du code front-end à la recherche d'URL malveillantes connues.
Seule une surveillance continue vous permet d'affirmer avec confiance que votre « site n'est pas vulnérable aux attaques par scripts susceptibles d'affecter le ou les systèmes de commerce électronique du commerçant ».
Les scripts côté client sont dynamiques et peuvent s'afficher de manière conditionnelle. Un acteur malveillant pourrait injecter une charge utile malveillante qui s'active dans des conditions spécifiques, par exemple en se déclenchant seulement 1 % du temps, à une heure précise ou uniquement pour des clients d'une région donnée.
En raison de ces techniques d'évasion et de furtivité, une approche basée sur des scanners est loin d'être idéale pour ce vecteur, car elle laisse beaucoup trop d'angles morts… mais dans certains cas c'est la seule option disponible, c'est pourquoi nous en proposons une en solution de dernier recours.
Êtes-vous éligible au SAQ A ? – Schéma
D'après notre interprétation, le questionnaire ci-dessous devrait vous aider à déterminer si vous êtes éligible au SAQ A :
Cependant, la formulation vague laisse place à l'interprétation, rendant difficile la détermination d'une conformité claire. En raison de ce manque de clarté, nous pensons qu'il est difficile de se qualifier pour le SAQ A avec certitude, d'autant plus que ces changements interviennent à l'approche de la date limite de conformité du 31 mars 2025.
En pratique, la plupart des commerçants auraient du mal à répondre « oui » avec assurance à la question :
« Le commerçant a confirmé que son site n'est pas vulnérable aux attaques par scripts susceptibles d'affecter le ou les systèmes de commerce électronique du commerçant. »
Un scénario possible serait que certains commerçants se précipitent pour adopter une configuration de page de paiement tierce, en supposant que cela renforce la sécurité et les rend éligibles au SAQ A. Pourtant, cela n'élimine pas le risque de vol de carte de crédit si les scripts de leur site web sont compromis, comme l'illustre la méthode de détournement de bouton.
Un autre scénario probable serait que des entreprises postulent simplement au SAQ A, en s'appuyant sur l'auto-évaluation, et espèrent le meilleur sans traiter les risques.
Des risques d'attaques côté client en hausse
Face au paysage actuel des menaces et à la complexité croissante des navigateurs modernes, les entreprises se trouvent à un tournant décisif.
En tant qu'entreprise de cybersécurité, nous prônerons toujours l'approche la plus sûre, celle qui protège activement les clients et les entreprises.
Les attaques côté client sont en augmentation. Plus de 600 000 sites web ont été touchés en 2024, et rien qu'en janvier 2025, nous avons détecté plus de 15 000 sites nouvellement impactés.
Votre responsabilité : une surveillance continue
La meilleure façon d'assurer la conformité PCI DSS est de surveiller l'intégralité de votre environnement côté client en temps réel. Il vous appartient de garder une longueur d'avance sur ces menaces et de protéger vos clients.
Pour toute clarification ou question, contactez-nous dès aujourd'hui.
