Un formulaire d'inscription est la chose la moins chère à attaquer sur Internet. Pas de mot de passe à deviner, pas de carte à voler, et chaque compte qu'il crée vaut quelque chose pour quelqu'un : un essai gratuit à revendre, un bonus de parrainage à farmer, une boîte pour le spam, ou un compte dormant pour une fraude future. Si vos inscriptions ont bondi du jour au lendemain et que votre taux d'activation a chuté, un script remplit probablement le formulaire.
Ce que vous coûtent les fausses inscriptions
- De l'argent : crédits gratuits, calcul d'essai, frais de vérification par SMS et e-mail, primes de parrainage.
- Des données : un entonnoir rempli de comptes qui ne convertiront jamais masque ce que font les vrais clients.
- La réputation : les e-mails de vérification vers des adresses inventées ou volées rebondissent et nuisent à votre score d'expéditeur.
- Les abus futurs : les comptes créés aujourd'hui servent le mois prochain au spam, au scraping ou au test de cartes.
Pourquoi un CAPTCHA n'est pas la réponse
Les services de résolution de CAPTCHA répondent aux énigmes pour bien moins d'un centime chacune, avec des personnes ou des modèles, donc un attaquant déterminé paie un peu et passe. Vos vrais visiteurs paient le prix fort : chaque énigme en perd quelques-uns, davantage sur mobile. Un CAPTCHA déplace le coût du mauvais côté.
Ce qui trahit une inscription par script
Aucun signal seul n'est une preuve, et tout ce que contrôle un attaquant, comme le User-Agent, peut être falsifié. Ce qui est difficile pour les scripts, c'est d'être cohérents sur de nombreux signaux à la fois, et de se comporter comme une personne dans la durée.
- Les indicateurs d'automatisation. Les navigateurs headless et pilotés se trahissent encore :
navigator.webdriver, un GPU logiciel, des fonctions de navigateur manquantes. - Les incohérences. Un User-Agent qui prétend être Windows sur un navigateur qui rapporte Linux, un fuseau horaire qui ne correspond pas au réseau, des client hints qui contredisent les en-têtes.
- Le réseau. Des inscriptions depuis des hébergeurs plutôt que depuis des foyers et des téléphones. Seul, c'est un indice faible : les utilisateurs de VPN sont aussi de vraies personnes.
- L'éventail. Un appareil, un token ou un sous-réseau qui crée de nombreux comptes en quelques minutes.
- Pas de page. Une requête à l'endpoint d'inscription depuis un client qui n'a jamais chargé la page d'inscription.
Décider sur le serveur, avant que le compte n'existe
La décision a sa place là où le compte est créé, pas dans le navigateur où un script peut la sauter. Avant d'insérer l'utilisateur, demandez une décision sur la requête, avec un timeout court :
POST /v1/decide
{ "ip": "203.0.113.10", "user_agent": "Mozilla/5.0 …",
"token": "<_kz cookie>", "path": "/signup" }Agissez ensuite selon la classe reçue, de la plus sûre à la moins sûre :
- bot high : refusez l'inscription.
- bot : créez le compte mais retenez ses crédits d'essai jusqu'à la vérification de l'e-mail, ou demandez un numéro de téléphone.
- unknown, human, human high : laissez passer comme d'habitude.
Retenir la récompense, plutôt que bloquer le formulaire, est ce qui rend les fausses inscriptions non rentables, sans refouler un vrai client dont le seul tort était un VPN.
Fail-open
Si la vérification est lente ou indisponible, laissez passer l'inscription. Quelques faux comptes pendant une panne coûtent bien moins qu'une page d'inscription qui ne fonctionne plus. Nous en parlons davantage dans pourquoi une vérification anti-bots doit être fail-open.