En bref : éligibilité à l'attestation SAQ A sur les scripts en janvier 2025
- Le piège de l'attestation : Retirer les exigences 6.4.3 et 11.6.1 du SAQ A n'a pas simplifié les choses. Cela les a remplacées par une auto-attestation selon laquelle « votre site n'est pas vulnérable aux attaques par scripts », et la plupart des commerçants n'ont pas l'expertise technique nécessaire pour évaluer précisément leur exposition aux attaques côté client.
- Ampleur des attaques : JavaScript est utilisé par 98,9 % de tous les sites web, et en janvier 2025, cside a détecté plus de 15 000 sites nouvellement touchés en un seul mois, avec plus de 600 000 sites impactés en 2024. Les vérifications par scanner passent à côté des attaques furtives qui ne se déclenchent que 1 % du temps ou dans une seule région.
- Défendre le oui : Si vous vous appuyez sur une redirection ou une iframe en pensant être protégé, sachez que les détournements de bouton et les faux formulaires superposés fonctionnent toujours. Pour répondre à l'attestation avec certitude, la surveillance continue côté client, comme celle proposée par cside, est le seul moyen de défendre le « oui ».
Peu de temps ? Découvrez cside PCI Shield. Elle couvre tout ce qui suit en un seul déploiement.
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. À la place, les commerçants doivent confirmer :
« 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 qui ne manipulent ni ne stockent eux-mêmes les données de paiement.
Cependant, cette nouvelle exigence d'auto-attestation a soulevé 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 de conformité liés aux 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 à ces deux exigences, et cet article explique ce que cette mise à jour signifie en pratique.
Nouvelles responsabilités pour les commerçants SAQ A
Le PCI SSC a élaboré ces Self-Assessment Questionnaires (SAQ) 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 désormais 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, pour de nombreux commerçants, les rendre 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'ampleur du changement de périmètre, nous estimons qu'une mise à jour est nécessaire pour garantir que les commerçants comprennent pleinement leurs obligations de conformité.
Qu'est-ce qu'un SAQ A et comment y répondre
Comme le formule le PCI SSC :
« Les commerçants SAQ A peuvent être des commerçants en ligne ou par courrier/téléphone (carte non présente), 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. »
Notez que les critères d'éligibilité actualisés 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, le commerçant ne conservant que des rapports papier ou des reçus contenant des données de compte. »
Et il est désormais également exigé du commerçant qu'il « confirme 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 la survenue 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 créent un faux sentiment de sécurité. Lorsqu'on utilise une iframe, il est quasiment 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 surviennent 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 du terme plus technique d'« attaques côté client » ou d'« 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ériques :
- 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 terminée, il est renvoyé vers le site du commerçant.
- Formulaire de paiement intégré : les informations de paiement sont collectées via une iframe ou un widget, intégrant un « mini-navigateur » tiers au sein du site du commerçant pour afficher le formulaire du prestataire de paiement.
- 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 comprendre où et quels risques côté client s'appliquent est essentiel pour 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 en tout point identique à la vraie, volant ainsi leurs informations de paiement au passage. Même en faisant appel à un prestataire de paiement tiers de confiance, les risques côté client subsistent. 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 plutôt les sites des commerçants à une exécution 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 vos achats en ligne et que vous cliquez sur le bouton « Pay Now » ci-dessous.
.pay-button:active { background-color: #166534; }
Payer maintenantEn voyant cette page, auriez-vous pensé que quelque chose clochait ?
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 véritable commerçant. Cela signifie que vous recevriez votre confirmation de commande et que tout se déroulerait comme prévu, tandis que les informations de carte de crédit seraient volées en même temps.
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 plus discrète, ils peuvent ne rediriger qu'un certain pourcentage de visiteurs, la limiter à certaines heures de la journée ou certaines régions, ou éviter les adresses IP propres au commerçant, permettant à l'attaque de passer inaperçue pendant longtemps.
En détournant le clic sur le bouton qui redirige l'utilisateur vers la page de paiement, le prestataire 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 véritable prestataire de paiement.
- En masquant la véritable iframe et en la remplaçant par un faux champ de saisie.
D'autres techniques permettent de capturer des informations sensibles tout aussi discrètement.
Lecture connexe : notre guide de conformité PCI DSS 6.4.3 et 11.6.1 · comment se conformer à PCI DSS 6.4.3
Tout JavaScript malveillant présent sur le site d'un commerçant aurait toute latitude sur la page et pourrait exécuter ces attaques. Le seul moyen d'éliminer totalement ce risque serait de supprimer tout JavaScript de la page de paiement ou de mettre en place des en-têtes CSP extrêmement stricts et des directives SRI, ce qui est rarement réalisable, car la plupart des prestataires de paiement (ainsi que des outils critiques courants comme les chatbots, les outils d'analyse de site ou les rapports d'erreurs) 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 avec des frameworks et plateformes tels que React, Vue, Magento, Drupal et WooCommerce. Atteindre ce niveau de sécurité manuellement, sans solution dédiée, est quasiment impossible sans un effort colossal et fragile.
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, comme 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, permettant un chargement plus rapide et une navigation fluide entre les pages.
Cependant, l'intérêt 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 se trouver.
Par conséquent, l'accent mis par la spécification d'origine sur les « scripts sur la page de paiement » devient inefficace pour les applications monopages, 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. Cela a parfaitement du sens, car les sites web remplissent des fonctions similaires et tout réécrire à partir de zéro reviendrait à réinventer la roue. L'utilisation de bibliothèques préconstruites accélère considérablement le développement web.
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 en continu.
Cet article Medium devenu viral de 2018 explique cette méthode de manière assez divertissante.
Les outils tiers
Une autre méthode d'injection courante consiste à détourner un script ou un outil tiers ajouté au site web. Il peut s'agir d'outils d'analyse, de publicité, de tests A/B, de widgets ou 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 a été un exemple majeur, illustrant l'usage réel de cette méthode d'attaque. Ce 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, s'approprier une URL S3 abandonnée, ou rejoindre un projet open source pour y 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 qu'elles sont fortement exposées aux injections côté client via des CVE courants.
Le nom « Magecart », terme historique désignant les attaques côté client, trouve son origine dans les injections côté client sur Magento utilisées pour voler les données des titulaires de carte. La menace dépasse désormais largement Magento : rien qu'en janvier 2025, nous avons détecté plus de 15 000 sites WordPress touchés par de nouvelles attaques côté client.
JavaScript est utilisé comme langage de programmation côté client sur 98,9 % de tous les sites web, ce qui en fait une cible privilégiée pour l'exploitation.
Par conséquent, sans sécurité côté client, il est impossible d'écarter une attaque avec certitude 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é de l'environnement côté client à l'aide d'un outil actif et en temps réel. Cette approche va au-delà des méthodes traditionnelles telles que les explorations ponctuelles, la revue manuelle des scripts d'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 certitude 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 ne s'active que dans des conditions spécifiques, par exemple en ne se déclenchant qu'1 % du temps, à une heure précise de la journée, ou uniquement pour des clients situés dans une région donnée.
En raison de ces techniques d'évasion et de furtivité, une approche fondée sur des scanners est loin d'être idéale pour ce vecteur, car elle laisse bien trop d'angles morts. Dans certains cas, cependant, c'est la seule option possible, 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 à interprétation, ce qui complique 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 peu avant l'échéance de conformité du 31 mars 2025.
En pratique, la plupart des commerçants auraient du mal à répondre « oui » avec certitude à la question suivante :
« 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 est que certains commerçants se précipitent pour adopter une configuration de page de paiement tierce, en supposant que cela améliore la sécurité et les rend éligibles au SAQ A. Pourtant, cela n'élimine pas le risque de vol de carte bancaire si les scripts de leur site sont compromis, comme l'illustre la méthode de détournement de bouton.
Un autre scénario probable est que des entreprises se contentent de postuler au SAQ A, en s'appuyant malgré tout sur l'auto-évaluation, espérant le meilleur sans traiter les risques.
Des risques d'attaques côté client en hausse
Les attaques côté client augmentent au même rythme que la complexité croissante des navigateurs modernes.
En tant qu'entreprise spécialisée dans la sécurité côté client, nous recommandons l'approche la plus protectrice possible, celle qui préserve à la fois les clients et les commerçants.
Les attaques côté client sont en hausse. 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.
