Champs de carte hébergés par le prestataire : tout est réglé ?

Non. Les champs de carte hébergés par le prestataire de paiement (affichés dans une fenêtre intégrée à votre page et servie par le prestataire) mettent les données de carte hors de portée de votre serveur et du code de votre page, et réduisent donc nettement le périmètre PCI DSS. Mais la page qui les entoure reste la vôtre, et c'est là que l'attaque peut se produire : un faux formulaire affiché avant le vrai, la fenêtre remplacée par une autre, un bouton qui mène ailleurs. Le PCI Security Standards Council lui-même indique que la page qui intègre le formulaire du prestataire reste dans le périmètre.

Ce que règlent les champs hébergés

Dans ce modèle, les champs numéro, date d'expiration et cryptogramme ne font pas partie de votre page : ils se trouvent dans une petite fenêtre intégrée (une iframe) dont le contenu provient de l'adresse du prestataire. Le navigateur isole les contenus d'adresses différentes ; le code exécuté sur votre page (y compris un code malveillant) ne peut donc pas lire ce que le client saisit dans cette fenêtre. Les données partent directement chez le prestataire.

C'est un vrai progrès. Moins de données transitent par la boutique, moins d'exigences s'appliquent et de nombreux commerçants peuvent utiliser le questionnaire d'auto-évaluation le plus simple, le SAQ A, s'ils remplissent ses critères d'éligibilité. Si vous utilisez des champs hébergés, continuez. L'essentiel est de ne pas confondre réduire le périmètre et supprimer le risque.

Là où le risque demeure

Le guide du PCI SSC sur la sécurité des pages de paiement, publié en mars 2025, est clair : intégrer le formulaire d'un tiers ne sort pas entièrement du périmètre la page qui l'affiche et ne rend pas inapplicables les exigences 6.4.3 et 11.6.1. Le commerçant répond des scripts de cette page et, lorsqu'un script crée la fenêtre, ce script est lui aussi concerné. En pratique, le fraudeur dispose de plusieurs voies sans jamais toucher aux champs du prestataire :

• Un faux formulaire avant le vrai. En février 2026, la société de recherche Sansec a décrit le cas d'une chaîne de supermarchés présente à l'international dont le vrai formulaire de carte venait du prestataire de paiement. Le code injecté dans la page de la boutique affichait d'abord un faux formulaire ; le client y saisissait ses données, voyait ensuite le formulaire légitime et les saisissait à nouveau. Selon Sansec, c'est précisément parce que la saisie de la carte s'est déplacée vers les formulaires des prestataires que les fraudeurs privilégient ce type de superposition.
• Remplacer ou masquer la fenêtre. C'est votre page qui indique au navigateur d'où charger la fenêtre de paiement. Si le code qui s'en charge est modifié, la fenêtre peut provenir d'une adresse ressemblante, ou rester cachée sous une couche identique.
• Détourner le bouton. Le bouton « Payer » et les étapes précédentes appartiennent aussi à votre page et peuvent être modifiés pour envoyer le client ailleurs.
• Les données hors de la fenêtre. Nom, e-mail, téléphone et adresse sont généralement saisis sur votre page, pas sur celle du prestataire.
• Les sites à page unique. Quand le navigateur ne recharge pas entre les étapes, les scripts chargés en début de visite restent actifs au paiement ; le guide considère toutes les vues comme concernées.

Ce qui a changé dans le SAQ A, et ce qui reste valable

En janvier 2025, le PCI SSC a retiré les exigences 6.4.3 et 11.6.1 du SAQ A, mais a ajouté un critère d'éligibilité : le commerçant doit confirmer que son site n'est pas exposé à des attaques par scripts susceptibles d'affecter ses systèmes de commerce électronique. Le Conseil a souligné que ce changement ne supprime ni n'affaiblit les exigences de fond du PCI DSS.

En février 2025, la FAQ 1588 a précisé que ce critère s'applique aux boutiques dont la page intègre le formulaire du prestataire, et non à celles qui redirigent le client vers le site du prestataire. Deux voies permettent d'y répondre : appliquer des techniques comme celles des exigences 6.4.3 et 11.6.1 pour protéger la page contre les scripts visant les données de compte, directement ou via un tiers ; ou obtenir du prestataire, conforme au PCI DSS, la confirmation que sa solution inclut cette protection pour la page du commerçant, lorsqu'elle est mise en œuvre selon ses instructions. Autrement dit, le questionnaire a raccourci, mais la question sur votre page est toujours là.

Liste de contrôle pour les utilisateurs de champs hébergés

• Demandez par écrit à votre prestataire si sa solution protège votre page contre les scripts et à quelles conditions, et suivez ses instructions d'intégration à la lettre.
• Traitez la page qui affiche le formulaire comme sensible. N'y gardez que les scripts indispensables et sachez qui peut la modifier.
• Inventoriez et surveillez les scripts de cette page, telle que le navigateur du client la reçoit.
• Vérifiez sur l'écran de l'acheteur que la fenêtre de paiement provient bien de l'adresse du prestataire et qu'aucun autre formulaire de carte n'apparaît avant ou par-dessus.
• Protégez ce qui se trouve hors de la fenêtre, comme le nom, l'e-mail et l'adresse.
• Prenez au sérieux les signalements de double saisie de la carte.
• Confirmez avec votre acquéreur le questionnaire applicable à votre boutique.

Proteside protège précisément la page qui entoure les champs du prestataire : il vérifie, dans le navigateur de l'acheteur, que le formulaire affiché est le légitime et provient de la bonne adresse, bloque les superpositions et produit la preuve des exigences 6.4.3 et 11.6.1. Découvrez la protection des paiements par carte et la solution de conformité PCI DSS, et essayez gratuitement pendant 14 jours.