TL;DR :
Reflectiz a publié une page de comparaison affirmant que cside est inefficace.
Aucune de ces affirmations ne résiste à un examen technique.
- Reflectiz est une solution de scan/crawl. Ils appellent cela « agentless », ce qui, à l'ère des navigateurs agentiques, est un terme prêtant à confusion. Ils scannent périodiquement votre site depuis des adresses IP cloud. Cette méthode est inefficace contre la plupart des menaces client-side. Les attaquants servent simplement des scripts propres aux scanners de sécurité et attaquent le reste. Les scanners voient ce que les attaquants leur permettent de voir, parce que les attaquants détectent le scanner. cside voit ce que les attaquants envoient réellement à vos utilisateurs, parce que cside s'exécute dans l'application.
- Ne nous croyez pas sur parole, c'est un fait architectural de base. Des recherches indépendantes menées par ISACA, des chercheurs en sécurité chez Google et Oracle, ainsi que des travaux académiques de l'Université de Bournemouth concluent de manière constante que les scanners sont incapables de suivre le rythme des menaces client-side dynamiques modernes.
- cside n'accède pas aux données des clients. Voir quels champs un script tente d'accéder ne signifie pas que le contenu saisi dans ces champs est exposé à cside.
- Pour déployer cside, vous collez 1 script dans votre code. Reflectiz, lui, doit contourner la détection des bots, nécessite des identifiants utilisateur et se cassera régulièrement lorsque les flux de paiement ou l'inventaire produit changent.
- cside n'affecte pas vos statistiques marketing, car cside n'interagit jamais avec les flux d'exfiltration de données. Un scanner qui tente de se comporter comme un utilisateur, lui, impacte bien les analytics.
- cside n'est pas uniquement une solution proxy. Nous disposons d'un mode direct, d'un Gatekeeper et également d'un scanner pour les sites où des modifications de code ne sont pas possibles.
- cside effectue une analyse dynamique et comportementale approfondie qu'aucun outil de scan ne peut égaler.
Cet article déconstruit certaines des allégations et explique pourquoi elles sont inexactes.
Introduction
La sécurité web fait face à de nouveaux défis. Les attaques sur la chaîne d'approvisionnement font régulièrement la une, et une part importante de cette chaîne concerne les dépendances qui s'exécutent dans le navigateur de l'utilisateur, là où vous n'avez aucune visibilité. Ces attaques ont considérablement évolué ces dernières années. À mesure que le paysage des menaces a évolué, les approches facilement contournables sont devenues obsolètes.
Ce qui mène à un résultat prévisible : les attaquants ne servent pas leurs attaques aux scanners de sécurité.
Récemment, Reflectiz a publié des comparaisons affirmant que cside serait moins performant que leur scanner. Ces affirmations ne reflètent pas les réalités technologiques de base. Elles témoignent d'une compréhension erronée de la sécurité client-side en tant que discipline, et du fonctionnement de cside.
Élément de contexte important : cside détient une attestation SOC2 type 2 et PCI SAQ-D. Reflectiz n'a ni l'un ni l'autre — il n'existe aucune preuve validée par un tiers que leur entreprise opère de manière sécurisée.
La précision est essentielle, surtout dans le domaine de la sécurité. Lorsqu'une solution de sécurité opportuniste met les utilisateurs en danger, nous en sommes tous perdants.
Les affirmations inexactes de Reflectiz à propos de cside
Fausse affirmation : cside collecte des données sensibles des clients
Reflectiz suggère que cside collecte des données sensibles telles que des mots de passe et des informations de carte bancaire. En réalité, cside surveille le comportement des scripts et n'a aucun accès aux saisies des utilisateurs. La notion de voir des données ou de voir quels scripts tentent d'accéder à quels champs de saisie ou APIs est une dimension entièrement différente.
- cside ne surveille pas les données saisies par les utilisateurs. Nous n'avons aucune visibilité sur ce qu'un utilisateur tape.
- cside surveille les événements d'un script.
Cela peut sembler répétitif, mais :
Nous n'interagissons pas avec les données qu'un utilisateur soumet via un formulaire sur un site web. cside surveille ce que les scripts tentent d'accéder.
Notre solution surveille les APIs du navigateur qu'un script tente d'utiliser, les champs de formulaire qu'il recherche et les destinations vers lesquelles les données sont envoyées.
Tout cela se produit sans toucher aux saisies des utilisateurs.
Même la solution Gatekeeper agit comme un « simple conduit », ce qui signifie que nous sommes un fournisseur de transit du contenu du script depuis le serveur tiers vers l'utilisateur. Nous pouvons faire partie de l'URL depuis laquelle le script est chargé, mais pas du flux d'exfiltration. La destination des données est uniquement surveillée en tant que point de terminaison.
Il existe une séparation fondamentale entre les actions des scripts et les actions des utilisateurs dans un navigateur, en particulier lors de la saisie de données. Ce sont littéralement des dimensions différentes. C'est un choix de conception essentiel pour préserver la confidentialité des clients et assurer la conformité réglementaire.
Rappelons que cside détient une attestation SOC2 type 2 et PCI SAQ-D. Reflectiz n'a ni l'un ni l'autre. L'intention d'un fournisseur sans aucune vérification de sécurité par un tiers qui formule des allégations sur les pratiques de collecte de données d'autrui est, au mieux, douteuse.
Fausse affirmation : le déploiement de cside prend des semaines
La plupart des clients déploient cside en quelques minutes en ajoutant un seul script à leur site. Rien d'autre n'est requis. cside prend en charge des configurations supplémentaires, comme le Gatekeeping sélectif de scripts non fiables ou de scripts opérant dans des zones particulièrement sensibles. Ces options sont proposées pour leur flexibilité, non parce que la plateforme l'exige.
Il n'y a aucune configuration DNS ou SSL, ni migration d'infrastructure.
L'affirmation selon laquelle cside nécessite de longs cycles d'intégration ne repose sur aucune réalité pratique d'utilisation du produit.
À l'inverse, le scanner de Reflectiz doit implémenter une logique pour contourner les captchas, vous demandera parfois d'autoriser leurs adresses IP dans votre solution de détection de bots, et nécessitera des identifiants utilisateur pour accéder aux pages de paiement. De plus, les sites web évoluent : pendant les périodes de soldes, le parcours d'achat sera différent d'un jour ordinaire. Ces changements peuvent faire échouer leurs scans. Si ne pas avoir à ajouter un script peut sembler plus simple, ce n'est pas l'image complète. Maintenir de manière fiable ce qui est nécessaire pour scanner la page dans la durée demande souvent un effort significatif et continu.
Fausse affirmation : cside est uniquement une solution proxy
Reflectiz présente cside comme une architecture purement proxy, sous-entendant une flexibilité de conception limitée et des problèmes potentiels de performance ou de fiabilité.
Le « mode Gatekeeper » de cside est optionnel. C'est l'un des plusieurs mécanismes disponibles pour les organisations souhaitant un contrôle supplémentaire sur les scripts chargés dans leur environnement. De nombreux clients n'utilisent pas du tout le service Gatekeeper et s'appuient plutôt sur la surveillance comportementale en temps réel.
Qualifier cside de « solution proxy » revient à ignorer la majeure partie de la plateforme.
Fausse affirmation : cside peut provoquer des interruptions de service ou perturber les analytics
cside utilise une conception fail-open. Si le service cside devient indisponible, le site du client se charge normalement. Il n'y a aucun blocage de l'exécution des scripts et aucun impact sur les fonctionnalités de la page. Si cside tombe en panne, le script qui ferait transiter le trafic via cside ne sera simplement pas servi. C'est une architecture de type dead-man switch basique — peu sophistiquée, mais très efficace dans les scénarios de défaillance.
Nous avons rédigé un article de blog complet à ce sujet ici.
Les systèmes d'analytics ne sont pas affectés, car cside n'interagit pas avec les données qui leur sont envoyées. Surveiller le comportement des scripts n'est pas la même chose qu'intercepter ou modifier des flux de données.
L'affirmation selon laquelle les analytics seraient perturbés témoigne d'une incompréhension de l'architecture de cside. Ce qui affecte bien les données analytics, en revanche, c'est un scanner qui tente de se comporter comme un utilisateur. Vous verrez ces requêtes arriver, elles rempliront un panier pour atteindre la page de paiement, puis l'achat sera abandonné, ce qui faussera vos métriques. C'est l'un des problèmes que vous rencontrerez avec une solution basée sur un scanner.
Fausse affirmation : Reflectiz détecte plus de scripts que cside
Reflectiz affirme détecter 20 à 50 % de scripts de plus que cside. Aucune méthodologie, source ou documentation n'accompagne cette assertion.
Ils affirment également que cside n'a pas de visibilité sur les iframes, ce qui est inexact. Nous collectons les URLs des iframes et examinons le contenu à l'intérieur de la session iframe via une vérification asynchrone. De plus, les iframes malveillantes sont généralement injectées via des balises script parentes. L'accent mis sur les iframes n'est pas aussi pertinent dans le monde réel, car l'objet iframe dans une attaque est rarement présent nativement — il s'agit généralement d'une sous-requête d'un script.
Plus important encore, la détection de scripts dans un environnement cloud n'équivaut pas à une protection efficace dans le trafic réel. Les scanners ratent intrinsèquement les types de menaces que les attaquants modernes utilisent :
- Attaques ciblant un user-agent spécifique
- Attaques ciblant uniquement les web-views
- Injections conditionnelles
- Attaques géo-ciblées
- Attaques à fenêtre temporelle
cside surveille le comportement des scripts dans le navigateur grâce à une analyse des actions en temps réel. Si une charge utile malveillante n'apparaît que pour les utilisateurs d'une certaine région ou dans certaines conditions, cside la verra. Un scanner, non.
Les scripts dont vous devez vous préoccuper ne vont pas se laisser piéger par un scanner.
Il existe un écart architectural indéniable entre le problème fondamental et le fonctionnement d'un scanner. Il ne s'agit pas de comparer le « nombre de scripts détectés », mais de savoir si un outil peut, par conception, observer les conditions dans lesquelles les attaques se produisent réellement.
Pourquoi ces inexactitudes sont importantes
Lorsque des fournisseurs formulent des affirmations inexactes sur le fonctionnement des outils concurrents, ils induisent en erreur les organisations qui s'appuient sur des informations précises pour protéger leurs utilisateurs.
Reflectiz a choisi la voie du moindre effort pour le client, ce qui séduit certainement certains. Cette approche a ses avantages et ses inconvénients. Ils ont opté pour la facilité d'adoption, mais cette approche est, en contrepartie, facile à contourner. Le problème, c'est qu'ils prétendent être les plus précis — ce qui est objectivement faux.
Les décisions en matière de sécurité doivent être éclairées par l'architecture, et non par des affirmations marketing incorrectes.
Les outils de scan ne détectent pas les menaces client-side modernes
Un crawler prend périodiquement des instantanés d'un site et tente de classer les scripts par leur URL ou leurs signatures connues. Les attaquants d'aujourd'hui :
- Injectent des charges utiles uniquement lors d'actions utilisateur spécifiques
- Servent du code différent selon les régions géographiques
- Modifient dynamiquement leur comportement après avoir pris l'empreinte de l'utilisateur
- Répartissent la logique malveillante sur plusieurs scripts
- Déclenchent des charges utiles uniquement dans des conditions de paiement ou de checkout où l'utilisateur est authentifié, évitant ainsi les identifiants utilisés dans les scénarios d'automatisation
Ces comportements sont invisibles pour les scanners. Pour approfondir le sujet, consultez notre article sur comment contourner les outils de scan.
Des recherches indépendantes menées par ISACA, des chercheurs en sécurité chez Google et Oracle, ainsi que des travaux académiques de l'Université de Bournemouth concluent de manière constante que la sécurité client-side basée sur des scanners ne peut pas suivre le rythme des menaces dynamiques modernes côté navigateur.
cside a été conçu en tenant compte de ces réalités. L'effort considérable que nous déployons pour construire une plateforme d'analyse comportementale en temps réel n'est pas vain — c'est parce que nous avons vu les scanners échouer encore et encore. Nous observons ce que les scripts font réellement lorsqu'ils s'exécutent sur de vraies pages pour de vrais utilisateurs, car nous savons que c'est la seule façon de détecter une attaque en cours.
C'est la seule approche défendable pour la sécurité client-side à l'échelle moderne.
Conclusion
Les affirmations formulées par Reflectiz sont manifestement générées par IA, avec peu de souci pour l'exactitude ou la légitimité.
Reflectiz a choisi de construire une solution qu'ils pouvaient déployer facilement pour leurs clients, simplifiant ainsi l'adoption. Construire un scanner est bien moins coûteux et complexe que de construire un service d'exécution en temps réel. Ce sont des choix de conception légitimes. Le problème, c'est qu'ils prétendent que leur solution — conçue pour être simple — est plus précise. Ce qui est tout simplement faux. Le choix technologique d'un scanner est une vérification ponctuelle. Pour un problème statique, cela peut suffire. Mais la sécurité client-side est un problème dynamique.
Il est important que des informations précises soient partagées, même dans les comparaisons concurrentielles. Cela implique également de reconnaître que les attaquants s'adaptent rapidement et exploitent les angles morts créés par des outils dépassés. cside est conçu pour éliminer ces angles morts grâce à une visibilité en temps réel alignée sur le fonctionnement des attaques modernes.
Choisir entre cside et Reflectiz
Nous aurions préféré ne pas avoir à écrire cet article, mais les informations trompeuses publiées par Reflectiz à notre sujet étaient trop outrancières pour être ignorées. Nous avons un article plus détaillé sur la comparaison entre nos solutions, disponible ici : cside vs Reflectiz Avec le temps, je pense que tout professionnel se retrouve face à un concurrent qui préfère investir son temps et son énergie à propager des désinformations et à user de tactiques agressives pour discréditer les autres plutôt qu'à améliorer son propre produit. C'est exactement ce type de situation.
