Alternatives à Akamai Client-Side Protection pour la page de paiement (2026)

Proteside enregistre ce qui est légitime sur chaque page de paiement (les données de chaque transaction, les champs du formulaire, les scripts autorisés) et vérifie en continu, dans le navigateur du payeur, ce qui est affiché, ce qui est copié et où vont les données. Lorsqu’il détecte une divergence, il arrête l’action avant la confirmation du paiement et consigne la tentative.

L’inventaire des scripts et l’historique des modifications constituent les preuves pour les exigences 6.4.3 et 11.6.1 de PCI DSS. L’installation tient en une ligne de code sur n’importe quelle plateforme e-commerce, ou en une seule intégration pour les plateformes et prestataires de paiement, avec tableau de bord, API et alertes.

La fonctionnalité, appelée Page Shield jusqu’en mars 2026 et désormais Client-Side Security, est disponible pour les domaines passant par le proxy Cloudflare. La documentation décrit la surveillance des scripts, des connexions et des cookies, la détection des scripts malveillants et des modifications de code, et des règles de sécurité de contenu capables de bloquer tout ce qui est hors de la liste d’autorisation.

La documentation elle-même explique le mécanisme : l’en-tête en mode rapport seul part sur un échantillon de réponses, si bien qu’un nouveau script peut mettre du temps à apparaître. Les exigences 6.4.3 et 11.6.1 sont couvertes dans le niveau avancé. Pix, le boleto (bordereau bancaire brésilien) et les systèmes de paiement instantané n’apparaissent pas dans le matériel.

Imperva (Thales) décrit Client-Side Protection comme un composant de sa protection applicative : découverte continue des services, analyse des scripts par IA, blocage en un clic, surveillance des modifications d’en-têtes, résumés hebdomadaires des modifications de la page de paiement et rapports exportables pour l’évaluateur, avec prise en charge de Terraform.

Le mécanisme est une politique de sécurité de contenu définie côté serveur selon un modèle zero trust : ce qui n’est pas autorisé ne se charge pas. La documentation publique décrit une fourniture via Imperva Cloud Application Security ; le périmètre est celui des scripts et des données de carte.

Feroot centre son offre sur la conformité : PaymentGuard couvre les exigences 6.4.3 et 11.6.1 avec un inventaire des scripts, des justifications, des contrôles d’intégrité et un rapport de preuves pour le QSA. La documentation publique cite des intégrations avec des outils d’alerte et d’exploitation, ainsi que la couverture des applications iOS et Android en plus des sites web.

Le point à surveiller pour quiconque est payé hors carte est le périmètre : le matériel public parle de scripts et de données de carte, sans mention des QR codes, des clés de paiement, du boleto (bordereau bancaire brésilien) ni des portefeuilles crypto. Pour ces moyens de paiement, une substitution du bénéficiaire se situe en dehors de ce que l’outil décrit vérifier.

c/side se définit comme une plateforme de sécurité côté client. Le matériel public décrit un inventaire avec l’historique du contenu de chaque script, un graphe des fournisseurs, des alertes, des tableaux de bord pour les exigences 6.4.3 et 11.6.1 et un point de réception des rapports CSP.

Sa page publique sur la crypto cite la substitution d’une adresse de portefeuille copiée dans le presse-papiers, ce qui la rapproche du problème que Proteside résout. Pix, le boleto (bordereau bancaire brésilien) et les QR codes des systèmes de paiement instantané comme UPI ou PromptPay n’apparaissent pas dans la documentation publique que nous avons consultée.

Reflectiz décrit sa propre approche comme sans agent : un navigateur en bac à sable simule le parcours utilisateur, inventorie les scripts (y compris dans les iframes), surveille les en-têtes pour l’exigence 11.6.1 et exporte les preuves pour le QSA. La plateforme couvre aussi la confidentialité et les tests offensifs.

Le matériel de l’éditeur lui-même explique le blocage comme un script qui reste inactif sur la page jusqu’à son déclenchement dans l’interface, moment où il commence à exclure un domaine via CSP. C’est un choix de conception : détection d’abord, intervention humaine ensuite. Les fraudes qui n’apparaissent qu’à un acheteur précis ne sont pas observées par les visites simulées.