Arrêtez de comparer les outils d'account takeover comme s'ils étaient interchangeables. Ils ne le sont pas. Un fournisseur MFA prouve qui se connecte, une suite fraude évalue ce que le compte fait après la connexion, et un outil de couche navigateur vous dit si la session qui tourne dans la page est même humaine. Ce sont trois tâches différentes à trois moments différents. Une grille de fonctionnalités qui les empile dans un seul tableau masque la question à laquelle vous devez répondre : quelle couche vous manque ?
Ce guide compare la prévention ATO par couche de défense (identité/MFA, suite fraude et navigateur+bot), et non par logo de vendor. Pour chaque couche, vous obtenez ce qu'elle voit, quand elle le voit, le trou qu'elle laisse ouvert, et où cside ajoute une preuve de couche navigateur que les deux autres ne peuvent pas capturer. Aucun prix inventé, aucune fausse checklist de fonctionnalités.
La raison pour laquelle le cloisonnement compte : les attaquants se déplacent le long d'un chemin. Les identifiants volés sont validés par des bots, les sessions valides sont détournées après que la MFA est passée, et la fraude n'apparaît qu'à la transaction. Chaque couche couvre une partie de ce chemin et devient aveugle sur le reste.
Comparer la prévention ATO par couche de défense
| Couche de défense | Ce qu'elle prouve | Quand elle agit | Angle mort qu'elle laisse |
|---|---|---|---|
| Identité / MFA | Qui s'authentifie | À la connexion, avant la session | Vol de session et AiTM après le passage du facteur |
| Suite fraude | Si les actions du compte paraissent risquées | Après la connexion, à la transaction | Sessions automatisées ou détournées qui agissent « normalement » jusqu'au paiement |
| Navigateur + bot | Si la session elle-même est humaine et fiable | Dans la page, pendant la session | Politique d'identité côté serveur et historique transactionnel inter-marchands |
Lisez le tableau par sa dernière colonne. La faiblesse de chaque couche est la raison d'exister d'une autre couche. Achetez pour fermer l'angle mort que vous avez réellement, pas pour collectionner la plus longue liste de fonctionnalités.
Couche 1, Identité et MFA : prouve qui, pas comment
La couche identité (Okta, Microsoft Entra ID et similaires) décide si un identifiant plus un second facteur doit ouvrir la porte. Les politiques adaptatives peuvent renforcer un défi quand le contexte de connexion paraît suspect, comme un nouvel appareil, une nouvelle géographie ou une vélocité étrange. C'est la fondation, et des facteurs résistants au phishing comme les passkeys (WebAuthn sous NIST SP 800-63B AAL2/AAL3) ferment le credential stuffing comme chemin.
L'angle mort est tout ce qui se passe après le passage du facteur. Un proxy adversary-in-the-middle laisse la victime s'authentifier normalement, MFA comprise, puis vole le token de session qui en résulte et entre. La couche identité a déjà renvoyé « success ». Elle n'a plus rien à dire. Si votre seul contrôle ATO est la MFA, une session volée ressemble exactement à l'utilisateur légitime.
Couche 2, Suites fraude : évaluent le compte, tard dans le chemin
Les suites fraude (Sift, Forter et leurs pairs) évaluent les événements tout au long du parcours (inscription, connexion, transaction) en utilisant des modèles de machine learning entraînés sur des données inter-marchands. Elles sont fortes à l'extrémité monétisation : pics de vélocité, changements d'adresse de livraison, changements de mode de paiement, flux de chargeback. Pour une entreprise avec une équipe fraude-ops et un vrai volume de chargebacks, cette couche se rentabilise.
Deux limites honnêtes. Premièrement, les signaux les plus forts arrivent tard, près de la transaction, après que l'account takeover a déjà eu lieu. Deuxièmement, l'intelligence appareil intégrée dans une suite est une fonctionnalité à l'intérieur d'un score boîte noire, pas un flux de signaux navigateur bruts que vous contrôlez. Quand une session automatisée se comporte comme un humain patient jusqu'au paiement, la suite la note souvent propre jusqu'à la fraude. Un account takeover piloté par bot est exactement le cas où ce score arrive trop tard.
D'après les données cside : les installations de playwright-stealth (un outillage d'automatisation conçu pour masquer qu'un navigateur est piloté par un script) ont augmenté d'environ dix fois sur 2025, selon le rapport de recherche de cside sur le futur de la sécurité web. C'est précisément le toolkit dont les suites fraude ont le moins de visibilité, parce qu'il imite un navigateur normal à la couche transactionnelle.
Couche 3, Navigateur et bot : cette session est-elle même humaine ?
La couche navigateur s'exécute dans la page et répond à la question que les deux autres ne peuvent pas : cette session est-elle un humain réel dans un vrai navigateur, ou un framework d'automatisation portant les identifiants d'un humain ? C'est la couche que la plupart des équipes sous-achètent, et elle se trouve exactement dans le trou entre « MFA passée » et « transaction liquidée ».
Signaux concrets que cette couche capture et qui n'atteignent jamais un score côté serveur :
navigator.webdriveret flags d'automatisation : la propriété que les navigateurs exposent quand une session est pilotée par WebDriver/CDP, plus les traces résiduelles que les plugins stealth essaient de corriger et manquent.- Fuites CDP et Runtime : activité du Chrome DevTools Protocol et artefacts
Runtimequi trahissent un navigateur headless ou piloté à distance même quand le user agent paraît ordinaire. - Dérive d'empreinte : le même « compte » qui présente des empreintes d'appareil incohérentes ou tournantes entre les connexions, une signature typique des fermes de bots et des outils partagés de rejeu de session.
- Comportement proxy résidentiel et VPN : des signaux comportementaux indiquant qu'une IP résidentielle autrement propre sert à blanchir du trafic automatisé, au-delà d'une simple blocklist d'IPs.
- Scripts malveillants dans la page : overlays de récolte d'identifiants ou logique de redirection AiTM injectés via des scripts tiers ou propriétaires, capturés au runtime avant que l'utilisateur ne soit phishé.
Ce dernier signal est le pont vers l'angle mort de la couche 1. Les attaquants injectent des overlays CSS et des scripts voyous sur des pages légitimes pour pousser les utilisateurs vers un faux login qui proxifie leur code MFA en temps réel. La couche identité voit une authentification propre ; la couche navigateur voit le script injecté et la session pilotée.
Comment acheter entre les trois couches
N'achetez pas la checklist la plus longue. Achetez la couche que votre chemin d'attaque laisse ouverte.
- Cartographiez votre chemin. Écrivez connexion → validation → accès → persistance de session → monétisation, et marquez quelle couche surveille chaque étape.
- Trouvez le point de défaillance unique. Si la MFA est votre seul contrôle ATO, votre trou est le vol de session. C'est un problème de couche navigateur, pas un problème de MFA plus forte.
- Évitez les signaux dupliqués sans action partagée. Deux outils qui signalent tous deux « nouvel appareil » sont du gaspillage si aucun ne peut faire respecter la décision.
- Menez une vraie preuve. Rejouez des incidents historiques à travers la couche candidate et vérifiez si elle aurait signalé la session, pas seulement la transaction.
- Câblez la passation. Un flag de couche navigateur doit déclencher une MFA renforcée à la couche 1 ou alimenter un score de risque à la couche 2, via API ou webhook, pour que chaque couche agisse sur les preuves des autres.
Où cside s'insère
cside est la couche navigateur-et-bot, et elle est conçue pour nourrir les deux autres plutôt que de les remplacer. Elle s'exécute côté client pour capturer les signaux d'appareil et d'IP réelle, la détection d'agents IA et de bots, la détection comportementale VPN/proxy, et la visibilité au runtime des scripts qui s'exécutent sur vos pages de connexion et de paiement. Ces signaux partent via API et webhook, de sorte qu'une inadéquation d'appareil ou un framework d'automatisation détecté peut déclencher une MFA renforcée chez votre fournisseur d'identité ou relever le score au sein de votre suite fraude.
cside ne proxyfie pas votre trafic et ne gère pas votre politique d'identité ni votre flux de chargebacks. Elle ferme le trou spécifique que les deux autres couches laissent ouvert, la session live, dans la page, entre l'authentification et le paiement, et remet les preuves aux outils qui possèdent l'application de la décision.
Pour aller plus loin sur cside
- Comparer les solutions de prévention d'account takeover
- Comment prévenir la fraude par account takeover : un guide en 4 étapes pour les entreprises
- Détection d'agents IA par cside
- cside Signup Shield, pour le problème en amont de la création de faux nouveaux comptes et de l'abus d'essais lors de l'inscription
