Protection anti-robot et anti-énumération
Un robot qui teste des adresses en série sur un formulaire laisse une trace : la forme même de ce qu'il soumet. YesWeCheck analyse quatre signaux sur le flux de chaque organisation, reconnaît trois familles d'attaque, et prévient par courriel avec un blocage en un clic. Sans configuration.
Ce que cherche un robot
Un formulaire de validation d'adresse répond à une question utile, et c'est ce qui le rend intéressant à détourner. Soumis des milliers de fois, il devient un instrument de découverte : l'attaquant apprend quelles adresses existent sur un domaine, sans avoir jamais eu à deviner juste du premier coup.
Le motif ne se voit pas sur une requête isolée. Chaque soumission est parfaitement ordinaire : une adresse, un domaine, une réponse. Ce qui trahit l'attaque, c'est la relation entre les soumissions, sur un même domaine, dans un même intervalle.
Les quatre signaux
Chacun mesure une forme de régularité que produit une machine et qu'une suite d'inscriptions humaines ne produit pas. Aucun ne suffit seul : c'est leur conjonction sur un même domaine, dans un même intervalle, qui distingue une campagne automatisée d'une journée d'inscriptions ordinaires.
| Signal | Ce qu'il mesure |
|---|---|
| A | Distance de Levenshtein moyenne entre les parties locales soumises sur un même domaine. |
| B | Progression numérique sur une racine commune, du type utilisateur1 puis utilisateur2. |
| C | Concentration de parties locales aléatoires sur un même domaine, signature d'une liste achetée en masse. |
| D | Effondrement de la diversité des n-grammes, signature d'une devinette par permutation du nom et du prénom. |
Les seuils ne sont pas publiés, et ils ne le seront pas. Publier le point exact où une alerte se déclenche reviendrait à publier le mode d'emploi pour rester juste en dessous.
Les trois familles d'attaque
Les signaux se regroupent en trois manières de s'y prendre, qui correspondent à trois intentions différentes. Reconnaître laquelle est en cours change ce que l'organisation doit faire : la première se bloque, la deuxième se filtre en amont, la troisième vise une personne précise.
| Famille | Signaux | Ce qui se passe |
|---|---|---|
| Énumération séquentielle | A, B | Un robot parcourt un formulaire en testant une suite d'adresses proches les unes des autres. |
| Injection de liste massive | C | Des adresses aléatoires arrivent en nombre sur un même domaine, récent ou jetable. |
| Devinette par permutation | D | Toutes les combinaisons du nom et du prénom d'une même personne sont essayées l'une après l'autre. |
La détection est silencieuse
La détection est silencieuse : aucun blocage n'est renvoyé à l'appelant, pour ne pas apprendre à l'attaquant qu'il est repéré. L'organisation reçoit une alerte par courriel, avec des exemples concrets et un blocage en un clic. Le blocage tombe donc quand elle le décide, pas au moment où l'attaquant pourrait s'en apercevoir.
C'est un choix de conception, et il va contre l'intuition. Renvoyer une erreur au moment où l'attaque est repérée serait satisfaisant, et ce serait une information offerte à l'attaquant : il saurait immédiatement quel rythme et quelle forme de soumission déclenchent la détection, donc comment y échapper.
L'API continue donc de répondre normalement. C'est l'organisation qui est prévenue, hors du canal que l'attaquant observe, et c'est elle qui décide du moment où le blocage tombe.
Où la protection s'applique
Les trois surfaces d'entrée sont couvertes de la même façon, sans réglage à faire. Une organisation qui valide ses adresses depuis son serveur, depuis un formulaire public et depuis un fichier importé bénéficie de la même analyse : c'est le flux qui est observé, pas le point d'entrée.
- API
- widget
- traitement par lots
Questions fréquentes
- Qu'est-ce que l'énumération d'adresses email ?
- C'est le fait de soumettre des adresses en série à un formulaire pour découvrir lesquelles sont acceptées. L'attaquant ne cherche pas à s'inscrire : il se sert de la réponse du formulaire comme d'un révélateur, pour reconstituer une liste d'adresses réelles sur un domaine.
- Pourquoi la détection ne bloque-t-elle pas la requête ?
- La détection est silencieuse : aucun blocage n'est renvoyé à l'appelant, pour ne pas apprendre à l'attaquant qu'il est repéré. L'organisation reçoit une alerte par courriel, avec des exemples concrets et un blocage en un clic. Le blocage tombe donc quand elle le décide, pas au moment où l'attaquant pourrait s'en apercevoir.
- Faut-il configurer quelque chose ?
- Non. La protection est active sur l'API, sur le widget et sur le traitement par lots, sans réglage. Il n'y a ni seuil à choisir, ni règle à écrire : l'analyse tourne sur le flux réel de chaque organisation, et l'alerte part quand un motif se dessine.
- Cette protection remplace-t-elle un captcha ?
- Non, elle ne joue pas au même endroit. Un captcha filtre avant la soumission et gêne l'attaquant comme le visiteur. Cette détection lit ce qui a déjà été soumis, sans rien demander à personne, et les deux se complètent plutôt qu'elles ne se remplacent.
Aller plus loin
L'énumération et l'injection de listes achetées se recoupent avec deux autres contrôles : la partie locale tirée au hasard et le domaine jetable. Une adresse aléatoire sur un domaine temporaire porte les deux signaux à la fois, et la réponse le dit contrôle par contrôle.
Faits relevés dans le code de YesWeCheck le 7 septembre 2026.