Le credential stuffing est une attaque automatisée qui rejoue à grande échelle, contre vos points d'entrée de connexion, des paires identifiant/mot de passe issues de fuites de données passées. Les attaquants misent sur la réutilisation des mots de passe : une paire volée sur un site fonctionne souvent sur des dizaines d'autres. Ce n'est pas de la devinette. Les identifiants sont déjà valides, et l'attaquant vérifie où ils ouvrent encore un compte.
Voici comment fonctionne l'attaque, pourquoi elle reste rentable, comment les bots à agent IA la rendent plus difficile à détecter, et quels signaux de connexion et contrôles permettent de la repérer et de la bloquer.
Qu'est-ce que le credential stuffing, et pourquoi fonctionne-t-il ?
Le principe est simple. Les attaquants assemblent des combolists de paires identifiant/mot de passe divulguées, puis les passent dans des outils automatisés contre l'API de connexion d'une cible. Ils n'ont pas besoin d'un taux de succès élevé. Même une fraction de pour cent sur des millions de tentatives donne des milliers de comptes fonctionnels.
Cela fonctionne parce que les gens réutilisent leurs mots de passe. Deux Américains sur trois réutilisent leurs mots de passe d'un compte à l'autre, selon security.org, ce qui signifie qu'une seule fuite compromet bien plus que le service touché. Cette réutilisation est tout le fondement économique de l'attaque.
Le credential stuffing se distingue de la force brute, et la différence compte pour la détection :
- La force brute devine de nombreux mots de passe contre un seul compte. Le trafic est bruyant et facile à limiter en débit.
- Le credential stuffing rejoue des paires connues comme valides sur de nombreux comptes. Le trafic ressemble davantage à des connexions normales, avec des taux de réussite plus élevés et un volume plus faible par compte.
Parce que les identifiants sont réels et que le volume par compte est faible, le stuffing se fond dans le trafic de connexion légitime. C'est pourquoi un seuil unique le détecte rarement.
Comment les bots à agent IA aggravent-ils le credential stuffing ?
Les anciens outils de stuffing étaient grossiers : des débits de requêtes élevés depuis une poignée d'IP, des user agents par défaut, aucun véritable navigateur. Les limites de débit et la détection de bots basique en venaient à bout dans la plupart des cas. Cette époque touche à sa fin.
La nouvelle vague passe par des navigateurs furtifs et des agents IA qui se comportent bien plus comme des humains. Ils :
- Font tourner les empreintes d'appareil et de navigateur d'une tentative à l'autre pour éviter d'être regroupés
- Résolvent les CAPTCHA, y compris les défis visuels et comportementaux
- Imitent le rythme humain, les mouvements de souris et les schémas de navigation
- Répartissent le trafic sur de vastes pools de proxys résidentiels pour déjouer les limites basées sur l'IP
- S'adaptent en temps réel à la manière dont vos défenses réagissent
Les kits de navigateurs furtifs font désormais partie de la trousse à outils standard de l'automatisation. Les installations de playwright-stealth, l'un des nombreux kits de navigateurs furtifs, ont été multipliées par 10 au cours de 2025, selon les recherches de cside. L'outillage pour mener des connexions automatisées convaincantes est bon marché et largement disponible.
Les défenses qui n'inspectent que les signaux de la couche réseau passent à côté de la moitié du tableau. Le navigateur est l'endroit où le bot opère, et où se trouvent les indices.
Quels signaux de connexion révèlent le credential stuffing ?
La détection fonctionne mieux en combinant des signaux, plutôt qu'avec une seule règle. La Credential Stuffing Prevention Cheat Sheet d'OWASP recommande de superposer les contrôles plutôt que de s'appuyer sur une seule vérification, car les attaquants ajustent leur comportement pour passer sous les seuils individuels.
Le tableau ci-dessous associe les signaux à plus forte valeur à ce qu'ils indiquent et à la manière d'y réagir.
| Signal | Ce qu'il indique | Comment réagir |
|---|---|---|
| Rafale de connexions / pic de vélocité | Rejeu scripté de nombreuses paires d'identifiants contre votre point d'entrée | Limiter le débit et brider par IP, par compte et par empreinte ; renforcer les défis |
| Empreinte de navigateur headless ou furtif | Automatisation se faisant passer pour un vrai navigateur | Bloquer ou défier la session ; router vers la détection de bots et d'agents IA |
| Nombreux comptes depuis un même appareil ou navigateur | Un acteur testant une combolist sur plusieurs comptes | Signaler l'appareil et exiger une vérification renforcée à chaque tentative |
| Déplacement impossible | Un même compte se connectant depuis des lieux inaccessibles dans le temps écoulé | Forcer une nouvelle authentification et examiner les changements récents du compte |
| Correspondance avec des identifiants compromis | La paire soumise apparaît dans des données de fuites connues | Forcer une réinitialisation du mot de passe avant l'accès ; bloquer l'identifiant à la réinitialisation |
| Ratio élevé d'échecs puis de succès | Sondage qui finit par tomber sur une paire valide | Mettre la session en quarantaine et exiger une MFA résistante au phishing |
| VPN, proxy ou IP malveillante connue | Trafic routé pour masquer son origine ou réutilisant une source signalée | Augmenter le score de risque ; combiner avec d'autres signaux avant de bloquer |
Aucune ligne ne constitue à elle seule une preuve. La détection la plus solide apparaît lorsque plusieurs se déclenchent ensemble dans une même session, par exemple une empreinte de navigateur furtif, plus une rafale de connexions, plus une correspondance avec des identifiants compromis. Un utilisateur réel ne produit presque jamais cette combinaison.
C'est aussi là que la visibilité au niveau du navigateur compte. Les rafales de connexions et la réputation d'IP se voient côté serveur, mais les navigateurs furtifs, la rotation d'empreintes et le comportement des agents IA n'apparaissent que lorsque vous pouvez lire ce que le navigateur fait réellement.
Comment bloquer le credential stuffing ?
La détection vous indique qu'une attaque est en cours. Pour la stopper, il faut des contrôles superposés, afin que le contournement de l'un ne livre pas le compte. Procédez dans cet ordre :
- Imposez une MFA résistante au phishing sur les connexions à forte valeur. Les passkeys et les clés de sécurité matérielles résistent au phishing et déjouent d'emblée les identifiants rejoués, car un mot de passe valide à lui seul ne suffit pas. OWASP désigne la MFA comme une défense principale contre le credential stuffing. Les codes à usage unique par SMS et e-mail sont plus faibles : réservez donc les méthodes les plus robustes aux flux sensibles.
- Bloquez les mots de passe connus comme compromis. Vérifiez les mots de passe par rapport aux bases de données de fuites lors de l'inscription et de la réinitialisation, et rejetez les correspondances. Si un identifiant actuel apparaît plus tard dans une fuite, forcez une réinitialisation avant qu'un attaquant ne puisse l'utiliser.
- Limitez le débit et bridez les points d'entrée de connexion. Appliquez des limites par IP, par compte et par empreinte d'appareil, pas seulement par IP, puisque les attaquants se répartissent sur des pools de proxys. Ajoutez des délais et des défis progressifs à mesure que le risque augmente.
- Ajoutez le fingerprinting ainsi que la détection de bots et d'agents IA. Utilisez le fingerprinting du navigateur et de l'appareil pour identifier l'automatisation, les navigateurs furtifs et les agents IA qui font tourner les empreintes et résolvent les CAPTCHA. Filtrez ce trafic avant qu'il n'atteigne l'authentification.
- Réagissez vite lorsqu'une session semble compromise. Révoquez les sessions actives, invalidez les jetons et forcez une nouvelle authentification. Examinez les changements de compte effectués après la connexion suspecte, comme la mise à jour de l'e-mail, du téléphone ou des coordonnées de versement.
La MFA est fondamentale, et elle ne suffit pas à elle seule. Les attaquants peuvent encore abuser de sessions volées, de proxys de phishing en adversary-in-the-middle et de flux de récupération faibles. Associer la MFA à des signaux au niveau du navigateur et de l'appareil comble ces lacunes. La même approche superposée sous-tend une défense plus large contre la prise de contrôle de compte, puisque le credential stuffing est la voie la plus courante vers l'ATO.
Où se situe la couche navigateur ?
Les utilisateurs réels, les utilisateurs frauduleux et les bots atteignent tous votre connexion via un navigateur. Cela fait du navigateur à la fois un canal de diffusion de code malveillant et une riche source de signaux sur l'identité réelle de celui qui se connecte.
Deux réalités de la couche navigateur façonnent la défense contre le credential stuffing :
- Le navigateur expose l'automatisation que le réseau masque. Les navigateurs furtifs, les runtimes headless, la rotation d'empreintes et le comportement des agents IA sont visibles dans l'environnement du navigateur, et non dans un paquet réseau. Lire ces signaux permet de distinguer les connexions scriptées des connexions humaines.
- Le navigateur peut être la surface d'attaque elle-même. Un script tiers compromis ou injecté sur votre page de connexion peut subtiliser des identifiants avant même que votre serveur ne voie la requête, ou rediriger les utilisateurs vers une connexion falsifiée. La surveillance de la sécurité côté client détecte les altérations de scripts que les contrôles réseau laissent passer.
cside est une plateforme de sécurité côté client conçue pour la couche navigateur. Elle combine la détection d'agents IA au fingerprinting de l'appareil et du navigateur pour faire remonter les signaux du tableau ci-dessus, puis les livre sous forme de signaux bruts via API afin que les équipes pilotées par les développeurs puissent les intégrer dans leur propre logique de risque pour la connexion et la récupération. Comme l'analyse est ancrée dans le navigateur, elle attrape les navigateurs furtifs et les bots à agent IA que les outils traditionnels, limités au réseau, ne voient pas.
Que doivent faire les équipes en priorité ?
Vous n'avez pas besoin de déployer tous les contrôles en même temps. Une séquence pratique :
- Activez le blocage des mots de passe compromis lors de l'inscription et de la réinitialisation. C'est peu coûteux et cela élimine une grande part des identifiants exploitables.
- Imposez une MFA résistante au phishing sur vos connexions à plus forte valeur avant de l'étendre plus largement.
- Instrumentez votre connexion avec les signaux de détection ci-dessus, puis ajustez les seuils sur des combinaisons plutôt que sur des règles isolées.
- Ajoutez le fingerprinting au niveau du navigateur et la détection d'agents IA afin de voir l'automatisation que les signaux réseau laissent passer.
Le credential stuffing prospère sur la réutilisation des mots de passe et l'automatisation bon marché. Contrez la première avec la MFA et les vérifications de mots de passe compromis, et la seconde avec la limitation de débit et la détection au niveau du navigateur.
Pour voir les signaux de la couche navigateur en action, réservez une démo ou consultez les tarifs de cside.
