Le PCI SSC a publié une FAQ sur l'éligibilité au SAQ A pour les entreprises, concernant les scripts présents sur leur site, en référence aux exigences 6.4.3 et 11.6.1 du PCI DSS 4.0.1.
Cette mise à jour a semé la confusion parmi les évaluateurs, nos clients et nos prospects.
Le SAQ A s'adresse aux commerçants qui externalisent entièrement le traitement des paiements à des prestataires de services tiers validés PCI DSS. Aucune donnée de titulaire de carte ne doit être traitée, stockée ou transmise via les systèmes du commerçant.
Une idée reçue courante est que l'utilisation d'une iframe ou d'une redirection suffit. Ce n'est pas le cas.
L'exigence clé est que le commerçant ne doit pas charger de scripts qui interagissent avec la page de paiement. Si des scripts provenant du domaine du commerçant ou de tiers sont présents, le SAQ A ne s'appliquera pas.
Le rôle des scripts dans la conformité SAQ A
- Le formulaire de paiement doit être hébergé et contrôlé entièrement par un prestataire conforme PCI.
- Le commerçant ne peut pas charger de scripts qui modifient, surveillent ou interagissent avec le formulaire de paiement de quelque manière que ce soit.
- Les seuls scripts autorisés doivent être directement gérés par le prestataire de paiement validé.
Si votre page de paiement inclut du JavaScript — que ce soit pour l'analytique, des améliorations d'interface ou des outils tiers en général — vous pourriez ne pas être éligible au SAQ A. Même si un script ne touche pas aux champs de paiement, il peut tout de même introduire des risques, tels que :
- Des attaques de form-jacking qui capturent les saisies utilisateur avant qu'elles n'atteignent le prestataire de paiement.
- Des modifications non autorisées du DOM affectant le processus de paiement.
- Des attaques de la chaîne d'approvisionnement exploitant des scripts tiers.
Une phrase suscite le débat
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.
Cette phrase a été ajoutée dans la mise à jour de janvier concernant les entreprises SAQ A.
Bien que le PCI DSS s'applique aux paiements et aux pages de paiement, cette phrase indique clairement que l'ensemble du site n'est pas vulnérable aux attaques par scripts. C'est logique. Par exemple, si un lien menant à une page de paiement n'est pas protégé ou surveillé, une injection de JavaScript malveillant par un tiers peut rediriger ce lien et compromettre quand même l'utilisateur.
La façon dont cela doit être démontré reste floue, ce qui engendre de la confusion.
Le PCI SSC renvoie à la dernière version de la liste PCI DSS SAQ A pour la liste complète des critères d'éligibilité, mais celle-ci ne fournit aucune information spécifiquement liée à la citation ci-dessus.
Dans la liste SAQ A, cette citation mentionne directement les scripts à surveiller et/ou à sécuriser :
En 6.4.3 (page 7) :
Tous les scripts de la page de paiement chargés et exécutés dans le navigateur du consommateur sont gérés comme suit : Une méthode est mise en œuvre pour confirmer que chaque script est autorisé. Une méthode est mise en œuvre pour garantir l'intégrité de chaque script. Un inventaire de tous les scripts est tenu à jour avec une justification écrite expliquant pourquoi chacun est nécessaire.
Dans cette section, seuls les scripts de la page de paiement sont mentionnés. Pourtant, les notes d'applicabilité ci-dessous précisent :
Cette exigence s'applique à tous les scripts chargés depuis l'environnement de l'entité ainsi qu'aux scripts chargés par des tiers et des quarts.
La notion d'« environnement de l'entité » brouille les frontières et ouvre la porte à l'interprétation de « leur site » dans son ensemble, telle qu'utilisée dans la phrase à l'origine de ce débat.
Parce que les sites chargent des scripts dynamiquement, un script provenant de n'importe quelle page peut persister jusqu'au paiement, en interférant potentiellement avec les transactions. Les scripts tiers, même sans lien direct ou chargés sur des pages antérieures à la page de paiement, peuvent introduire des vulnérabilités.
Sur les Single Page Apps (SPAs), les scripts persistent d'une vue à l'autre, ce qui signifie qu'un script chargé sur n'importe quelle page peut rester actif pendant le paiement. De même, avec les Progressive Web Apps (PWAs), les scripts s'exécutent en continu pendant la navigation de l'utilisateur, augmentant le risque d'interactions non souhaitées avec le flux de paiement.
En 11.6.1 (page 16), notes d'applicabilité :
L'intention de cette exigence n'est pas qu'une entité installe des logiciels dans les systèmes ou navigateurs de ses consommateurs, mais plutôt que l'entité utilise des techniques telles que celles décrites dans les Exemples de la colonne Guidance du PCI DSS (des Exigences PCI DSS et Procédures de test) pour prévenir et détecter les activités de scripts inattendues.
Ce chemin nous mène à ces exemples, que l'on trouve dans la liste SAQ A à la page vi. Dans la section « Non applicable », il est indiqué :
L'exigence ne s'applique pas à l'environnement du commerçant. (Voir « Guidance for Not Applicable Requirements » ci-dessous pour des exemples.) Toutes les réponses dans cette colonne nécessitent une explication justificative dans l'Annexe D de ce SAQ.
Un seul exemple figure dans « Guidance for Not Applicable Requirements » :
Les exigences relatives à la sécurisation de tous les supports contenant des données de titulaires de carte (Exigences 9.4.1 - 9.4.6) ne s'appliquent que si un commerçant stocke des supports papier contenant des données de titulaires de carte ; si aucun support papier n'est stocké, le commerçant peut sélectionner Non applicable pour ces exigences.
L'« Annexe D » désigne simplement un espace où l'entreprise candidate au statut SAQ A, ou les évaluateurs qui l'évaluent, peuvent consigner leurs constatations et conclusions sur ce sujet.
Comment être conforme ?
En plus de toutes les autres exigences SAQ A, les entreprises doivent prouver que leur site est protégé contre les attaques non autorisées par scripts. La façon dont elles le prouvent reste ouverte. Chez cside, nous avons créé un outil qui y répond et permet aux entreprises de cocher les cases des exigences 6.4.3 et 11.6.1. Selon la configuration du site, d'autres approches sont possibles, à condition qu'elles respectent les autres exigences nécessaires à l'éligibilité au SAQ A.
Devez-vous vous conformer aux exigences 6.4.3 et 11.6.1 ?
Si vous êtes éligible au SAQ A, vous êtes techniquement exempté des exigences 6.4.3 et 11.6.1.
Cependant, l'éligibilité au SAQ A exige que vous confirmiez que l'ensemble de votre site n'est pas vulnérable aux attaques par scripts susceptibles de compromettre votre système de commerce électronique. Bien que le PCI SSC ne définisse pas explicitement comment valider cela, cela signifie que vous devez vous assurer que :
- Aucun script non autorisé ne s'exécute sur votre site.
- Votre processus de paiement est protégé contre les manipulations (par exemple, le détournement de redirections).
- Vous surveillez et sécurisez toutes les intégrations tierces.
Si vous n'êtes pas éligible au SAQ A, vous devez vous conformer aux exigences 6.4.3 et 11.6.1, car votre environnement relève d'une catégorie de conformité plus élevée nécessitant des contrôles de sécurité supplémentaires.
Et tout cela s'applique à l'ensemble du site, comme le stipule la phrase : « 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. »
Exemples de non-éligibilité (SAQ A non autorisé)
- Une page de paiement personnalisée avec des appels API directs à un processeur (SAQ D requis).
- Une page de paiement incluant des scripts non sécurisés affectant les champs de paiement.
- L'utilisation de champs hébergés par un tiers mais modifiés via JavaScript.
- L'absence de confirmation que le site n'est pas vulnérable aux attaques par scripts susceptibles d'affecter les systèmes de commerce électronique du commerçant.
Conclusion
Le SAQ A offre une voie de conformité simplifiée aux commerçants capables d'externaliser entièrement le traitement des paiements, mais les dernières clarifications mettent en évidence un changement important : les responsabilités en matière de sécurité ne s'arrêtent pas à la page de paiement.
Bien que les exigences 6.4.3 et 11.6.1 ne s'appliquent pas aux commerçants SAQ A, s'assurer que l'ensemble du site est protégé contre les attaques par scripts est désormais une obligation.
Cela signifie que les commerçants doivent adopter des mesures de sécurité proactives — non seulement pour maintenir leur conformité, mais aussi pour prévenir les menaces susceptibles de compromettre leur écosystème de commerce électronique. Les CSP, SRI et la surveillance de l'intégrité des scripts sont appelés à devenir des exigences de base plutôt que des protections optionnelles.
Avec cside, vous êtes automatiquement conforme aux exigences 6.4.3 et 11.6.1.
Nous aidons les commerçants à détecter, surveiller et atténuer les risques liés aux scripts. Si vous avez des doutes sur votre conformité, nous pouvons vous aider à cocher les cases et rester en sécurité.
Contactez-nous pour sécuriser votre environnement côté client et maintenir votre conformité SAQ A en toute confiance.
