Alternatives à F5 Client-Side Defense 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.

Client-Side Protection & Compliance (anciennement Page Integrity Manager) inventorie les scripts, applique des justifications et des règles, surveille les en-têtes pour l’exigence 11.6.1 et alerte sur les scripts non autorisés, l’exfiltration de données de paiement et les altérations. La documentation publique indique que les détections fonctionnent pour n’importe quel site, où qu’il soit hébergé, avec une configuration dans la console Akamai.

L’injection du script peut être réglée sur un pourcentage des pages vues, et la mitigation est décrite comme une restriction appliquée en un clic. Pour une couverture complète, l’injection doit s’exécuter sur chaque page vue. Le matériel couvre les scripts et les données de carte ; il n’aborde ni les QR codes, ni les clés de paiement, ni les lignes de boleto.

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.