Comment stopper les fausses inscriptions : détecter les faux comptes par type d'IP

Okta Threat Intelligence a décrit un service de vidéo par IA dont l'essai gratuit a attiré un déluge de tentatives de fausses inscriptions. Dans les journaux d'un client, « entre le 1er juin 2026 et le 1er juillet 2026, les journaux montrent plus de 105 000 tentatives d'inscription par force brute depuis 251 IP distinctes probablement liées à des bots ». Les inscriptions « étaient liées à des fournisseurs de proxy et à des VPN ». D'après le calcul de GeoIPHub sur les chiffres d'Okta, cela représente environ 418 tentatives par adresse sur le mois, soit environ 14 par jour, donc une limite de quelques inscriptions par IP et par heure pourrait ne jamais se déclencher.

La difficulté, c'est que les fausses inscriptions et les vrais clients partagent les mêmes réseaux. De vraies personnes utilisent aussi des VPN et des postes de travail dans le cloud, et les adresses que de vraies personnes partagent, comme iCloud Private Relay, les opérateurs mobiles et le CGNAT, paraissent chargées par nature. Une règle qui ne fait que bloquer laissera entrer le pool ou bien enfermera les clients dehors.

Ci-dessous : sept adresses d'où peut provenir une inscription, ce que l'API de recherche IP de GeoIPHub a renvoyé pour chacune le 2 novembre 2026 et ce que nous ferions au niveau du formulaire, pourquoi les adresses partagées ne doivent jamais être refusées sur le seul score, des limites de vélocité avec du code testé, et ce que l'IP ne peut pas voir.

Ce que vérifie la détection des faux comptes à l'inscription, et le seul signal dont vous disposez toujours

La détection des faux comptes évalue chaque nouvelle inscription selon le réseau, la vélocité, l'e-mail, le téléphone, l'appareil et le comportement. Au moment où le formulaire est envoyé, l'IP est le seul de ces éléments dont votre serveur dispose toujours sans rien demander à l'utilisateur, c'est pourquoi un score de fraude IP est la première vérification habituelle.

L'OWASP nomme cette attaque OAT-019 Account Creation : « Création de comptes en masse, et parfois remplissage de profils, en utilisant les processus d'inscription de l'application. » La création de faux comptes est rarement l'objectif ; elle prépare l'exploitation des promotions et des parrainages, un seul opérateur derrière de nombreux comptes qui contourne un bannissement, ou la mise en place de campagnes de credential stuffing.

La fraude à l'inscription est assez courante pour qu'il faille s'y préparer. Le Customer Identity Trends Report 2025 d'Okta, établi à partir de sa plateforme Auth0, indique : « En 2024, en moyenne 46 % de toutes les tentatives d'inscription sur la plateforme Auth0 ont été identifiées comme des attaques à l'inscription. » Stripe, en annonçant Sessions 2026 le 29 avril 2026, a formulé ainsi le chiffre de son propre réseau : « Sur l'ensemble des services d'IA qui fonctionnent avec Stripe, une tentative d'inscription sur six est le fait d'un acteur malveillant. »

Voici ce dont chaque couche a besoin, et celles auxquelles une requête IP peut répondre :

La ligne de l'appareil relève d'un autre outil ; notre comparaison entre l'empreinte d'appareil et les données IP explique comment les deux se combinent.

Sept IP d'inscription, sept décisions : ce que GeoIPHub a renvoyé le 2 novembre 2026

GeoIPHub a interrogé sept adresses d'où peut provenir une inscription entre 04:51 et 04:52 UTC le 2 novembre 2026. Voici le score, les raisons et ce que nous ferions au niveau du formulaire, en utilisant la ligne inscription des seuils de départ du score de fraude de GeoIPHub. Les deux dernières lignes sont des règles de notre configuration de scoring, pas des requêtes.

Les deux 100 semblent identiques et ne le sont pas. Le nœud de sortie Tor porte un historique de spam ; le serveur VPN ne porte que des raisons d'anonymat, sans aucune preuve d'abus. Cette différence détermine si une inscription via VPN est refusée ou vérifiée.

Le recommended_action de l'API elle-même ne bloque qu'au-dessus de 75. Les seuils de départ de GeoIPHub pour l'inscription bloquent à partir de 71, et aucune ligne du 2 novembre 2026 ne tombait entre les deux.

Le haut débit domestique n'a pas de ligne, car nous ne publions pas d'adresses de foyers. Le scoring de GeoIPHub n'accorde sa réduction à une ligne domestique que lorsque l'adresse a un nom DNS inverse de type résidentiel, donc une ligne domestique sans un tel nom n'obtient aucune réduction résidentielle, et toute raison de menace compte en totalité.

Lisez les raisons, pas le chiffre : une inscription suivie de bout en bout

Le score dit à quel point une adresse est risquée ; scoring.detection_methods dit pourquoi, et ce pourquoi permet de choisir entre restreindre, vérifier et refuser. Voici la réponse abrégée pour 45.83.220.7, interrogée à 04:51:58 UTC le 2 novembre 2026 :

Deux raisons se sont déclenchées. known_vpn_server ajoute 36 (40 points à une confiance de 0,9) et datacenter_ip ajoute 10 (20 à 0,5), le score est donc de 46. Il tombe dans la tranche 26 à 50 des seuils de départ de GeoIPHub pour l'inscription : créer et signaler. Nous créerions le compte dans un état restreint, sans crédits d'essai ni bonus tant que l'e-mail n'est pas confirmé. Comme detection.is_hosting vaut true, l'inscription compte aussi pour l'AS39351 dans le contrôle de vélocité ci-dessous. Au premier événement de valeur, comme le début d'un essai ou l'attribution de crédits, interrogez à nouveau l'IP.

Le serveur Mullvad 185.213.155.73 a obtenu 100 block, et chacune de ses quatre raisons concerne l'anonymat, pas l'abus. Par défaut, à l'inscription, il faut le refuser. Les produits dont les vrais utilisateurs utilisent des VPN peuvent écrire des règles sur les raisons et envoyer un 100 comme celui-ci, avec des raisons d'anonymat et aucune raison d'abus, vers une vérification par e-mail ou par téléphone. Un VPN seul est un choix de confidentialité, et les personnes qu'il protège sont souvent celles qui sont signalées à tort. Un nœud de sortie Tor avec un historique de spam reste refusé dans tous les cas.

Un score de 0 n'est pas un laissez-passer : robots d'exploration et scanners sur votre formulaire d'inscription

Les deux résultats les plus favorables des requêtes de GeoIPHub du 2 novembre 2026, le Googlebot vérifié en 66.249.66.1 et le scanner Censys en 162.142.125.10, ont tous deux obtenu 0 allow, et ce sont justement les deux qui ne devraient jamais créer de compte. Cela nous a davantage surpris que n'importe quel 100.

La raison verified_crawler de GeoIPHub retranche 28,5, donc un robot d'exploration vérifié se retrouve en bas de l'échelle. C'est juste pour l'exploration et faux pour un POST de formulaire. Si threat.crawler.verified vaut true sur une requête d'inscription, ne créez pas le compte. Lisez pour cela crawler.verified et crawler.operator, jamais crawler.name.

threat.is_scanner n'alimente pas du tout le score : l'adresse de Censys n'a renvoyé aucune raison. Vérifiez directement l'indicateur et refusez l'inscription lorsqu'il vaut true.

Ne refusez jamais une adresse partagée sur le seul score : relais, CGNAT et mobile

Une sortie iCloud Private Relay, une adresse CGNAT ou une passerelle mobile peut porter de nombreuses vraies personnes. Le scoring de GeoIPHub plafonne les adresses de relais à 60 et les adresses CGNAT à 50, sauf si l'adresse porte ses propres preuves de menace, et accorde une réduction aux adresses mobiles saines, tandis qu'une adresse mobile avec des preuves de menace reçoit au contraire une pénalité. Vos règles doivent maintenir ces adresses hors de la tranche de blocage, sauf si elles portent leurs propres preuves.

Dans le scoring de GeoIPHub, relay_ip ajoute 8,5 et il n'existe pas de réduction pour les relais, donc notre échantillon de relais a obtenu 9. Le plafond CGNAT ne se lève qu'avec des preuves propres à l'adresse : VPN, proxy, Tor, protocole, botnet ou abus. Les adresses d'opérateurs mobiles reçoivent mobile_carrier, qui abaisse le score de 12 en l'absence de preuve de menace.

Rien de tout cela ne signifie « confiance ». Cela signifie que l'IP seule ne peut pas distinguer l'unique acteur malveillant des nombreux clients derrière la même adresse. Soumettez donc ces inscriptions à un défi, ne les refusez jamais sur le score, et accordez-leur dix fois les limites de vélocité habituelles. Pour Private Relay en particulier, le conseil est de les laisser passer et d'évaluer la session selon ce que fait ensuite le compte.

Comptez les inscriptions par IP, par /24, par /64 IPv6 et par réseau d'hébergement dans votre propre code

L'API de GeoIPHub évalue une adresse ; elle ne compte pas combien de comptes cette adresse, son /24, son /64 ou son réseau ont créés au cours des dernières 24 heures. Ce compteur vit dans votre code, et la requête vous indique quelles clés utiliser : asn.asn, detection.is_hosting, detection.is_relay, detection.is_mobile, asn.connection_type et threat.is_cgnat.

Dans le cas du service de vidéo par IA d'Okta, les tentatives de fausses inscriptions s'élevaient en moyenne à environ 14 par adresse et par jour, réparties sur 251 adresses. Un compteur par IP seul pourrait ne jamais se déclencher. Les compteurs par préfixe et par réseau existent précisément pour ce cas.

Ce sont des points de départ que nous avons choisis, pas des références du secteur ; ajustez-les sur vos propres inscriptions.

Dépasser la limite signifie renforcer la vérification (par e-mail ou par téléphone, ou par CAPTCHA) ou créer un compte restreint, pas refuser. En IPv6, comptez le préfixe, jamais l'adresse complète, sinon un seul acteur devient des milliers d'inscriptions « différentes ». Les foyers reçoivent couramment un /56 ou un /48, d'où l'élargissement dans le tableau ; notre guide pour limiter le débit IPv6 par préfixe détaille les tailles d'allocation.

Le code ci-dessous fonctionne sous Node 18 ou plus récent, sans dépendance. Il attend l'adresse du client telle que Node la rapporte, y compris les formes IPv4 mappées comme ::ffff:192.0.2.1, après que vous l'avez extraite de votre chaîne de proxys de confiance. Il utilise des fenêtres fixes, ce qui est une simplification d'une fenêtre glissante.

Nous avons exécuté 16 tests unitaires sur ce code exact le 2 novembre 2026 sous Node 24.20.0, en utilisant des plages d'adresses de documentation et privées ainsi que l'adresse scanme.nmap.org du tableau, sans aucune requête. Les 16 ont réussi : les formes IPv4 mappées comme ::ffff:45.33.32.156 ont été traitées comme des clés IPv4, la rotation à l'intérieur d'un même /64 s'est déclenchée à la 4e inscription, 11 adresses réparties dans un même /24 n'ont déclenché que la clé /24, et 30 inscriptions depuis une même sortie de relais sont passées tandis que la 31e a été signalée. Une requête échouée (null) produit tout de même les clés d'IP et de préfixe, donc le compteur continue de fonctionner lorsque l'API ne répond pas.

Là où la couche IP devient aveugle

Une requête IP ne peut pas voir un faux compte qui s'inscrit depuis une connexion domestique louée ou un vrai téléphone, et elle ne voit jamais l'e-mail, l'appareil ni la manière dont le formulaire a été rempli.

Les proxys résidentiels sont la lacune la plus nette. GeoIPHub signale les proxys que nous avons observés sur des lignes résidentielles et mobiles, y compris les adresses qu'une liste tierce indique comme servant de relais, mais nous n'avons pas de détection propre des proxys résidentiels, et une ligne domestique saine peut passer. Les fermes à clics et les fermes d'appareils qui fonctionnent sur de vraies cartes SIM ressemblent à des clients mobiles, et notre scoring traite délibérément les clients mobiles avec indulgence.

GeoIPHub évalue l'IP ; il ne vérifie ni les adresses e-mail ni les numéros de téléphone. Associez la vérification IP à vos propres vérifications d'e-mail (domaines jetables, normalisation des adresses avec signe plus et avec points), à la vérification du téléphone, aux signaux de l'appareil et au regroupement des comptes qui partagent des clés après l'inscription.

C'est l'état restreint qui rend la tranche intermédiaire peu coûteuse à gérer. Créez le compte, retenez les crédits, et libérez-les après la vérification ou la première action réelle. Un faux compte qui ne se vérifie jamais vous coûte une ligne en base de données, pas un essai.

Comment stopper les fausses inscriptions avant que le compte n'existe

L'ensemble de la vérification se résume à une requête et à un comptage de vélocité entre « envoyer » et « créer », dans cet ordre :

1. Prenez l'IP du client dans votre chaîne de proxys de confiance, pas dans un en-tête X-Forwarded-For brut, que le client peut définir comme il veut.
2. Interrogez l'IP.
3. Refusez les nœuds de sortie Tor, les robots d'exploration vérifiés et les scanners. Refusez par défaut un serveur VPN à 100, ou envoyez-le en vérification si vos utilisateurs utilisent des VPN et qu'aucune raison d'abus ne s'est déclenchée. Ne refusez jamais les adresses de relais, CGNAT ou mobiles sur le score. Appliquez les seuils de départ de GeoIPHub pour l'inscription à tout le reste.
4. Exécutez le contrôle de vélocité et renforcez la vérification en cas de dépassement.
5. Si la requête échoue, rabattez-vous sur le contrôle de vélocité et la confirmation par e-mail ; ne refusez pas.
6. Conservez le score, les raisons et l'heure de la requête avec le compte, et interrogez à nouveau l'IP au premier événement de valeur (début d'essai, attribution de crédits, premier versement).

Notre intégration Node et Python testée montre les étapes 2 et 3 sous forme de code fonctionnel. L'offre gratuite de GeoIPHub couvre 1 500 requêtes par jour avec tous les champs inclus.

Collez les dix dernières IP de votre journal d'inscriptions dans l'outil de vérification du score de fraude IP et classez-les selon les lignes du tableau. Le score vous dit ce qu'est chaque adresse ; le compteur vous dit combien de comptes elle a créés.

Questions fréquentes

Comment stopper les fausses inscriptions sans bloquer de vrais utilisateurs ?

Interrogez l'IP de chaque inscription avec l'API de GeoIPHub avant de créer le compte. Refusez les nœuds de sortie Tor et les scores les plus élevés, vérifiez la tranche intermédiaire par e-mail ou par téléphone, et laissez passer les adresses partagées comme iCloud Private Relay, le CGNAT (NAT de niveau opérateur) et les passerelles mobiles avec des limites de vélocité plus souples, car une seule de ces adresses peut porter de nombreux vrais clients.

La fraude à l'inscription est-elle courante ?

Sur la plateforme Auth0 d'Okta, en moyenne 46 % des tentatives d'inscription en 2024 ont été identifiées comme des attaques à l'inscription. Stripe a indiqué en avril 2026 qu'une tentative d'inscription sur six aux services d'IA de son réseau est le fait d'un acteur malveillant. Il s'agit dans les deux cas de chiffres de fournisseurs, issus de leurs propres plateformes.

Une adresse IP seule permet-elle de détecter les faux comptes ?

Non. Une requête IP montre de quel type de réseau provient l'inscription et pourquoi elle a obtenu ce score, mais elle ne voit ni l'e-mail, ni le téléphone, ni l'appareil, ni un faux compte qui s'inscrit depuis une connexion domestique louée. Utilisez-la comme première couche et associez-la à des vérifications de l'e-mail, du téléphone et de l'appareil.

GeoIPHub vérifie-t-il les adresses e-mail ?

Non. L'API de GeoIPHub n'évalue que l'adresse IP. Vérifiez l'e-mail et le téléphone avec vos propres outils et combinez ces résultats avec le score et les raisons de GeoIPHub.

Faut-il autoriser un utilisateur de VPN à s'inscrire ?

Souvent, oui. Un VPN en soi est un choix de confidentialité, vous pouvez donc envoyer les inscriptions via VPN vers une vérification par e-mail ou par téléphone au lieu de les refuser, et réserver les blocages purs et simples aux nœuds de sortie Tor et aux adresses ayant un historique de spam ou d'abus.

Comment limiter le débit des inscriptions en IPv6 ?

Comptez par /64, pas par adresse, car un seul abonné peut faire tourner ses adresses dans tout un /64. Élargissez au /56 ou au /48 lorsque de nouveaux /64 issus de la même allocation continuent d'arriver, et gardez des limites plus souples pour les opérateurs mobiles.