À partir de quel score de fraude IP faut-il bloquer ?

Il n'existe pas de seuil de score de fraude IP unique à partir duquel bloquer : le même score peut laisser passer une connexion, signaler une inscription pour revue et envoyer un paiement vers 3-D Secure. L'échelle de 0 à 100 de GeoIPHub autorise par défaut jusqu'à 25, met en revue jusqu'à 50, renforce l'authentification jusqu'à 75 et bloque au-delà de 75, et ce guide déplace ces lignes action par action, testées sur cinq adresses publiques le 22 octobre 2026.

Un score, trois portes : cinq IP soumises aux seuils

Le même verdict de l'API n'a pas les mêmes conséquences à chaque porte, et deux plafonds de score déterminent ce qu'une adresse partagée peut atteindre. Le 22 octobre 2026 à 04:56 UTC, nous avons interrogé cinq adresses publiques avec l'API sans clé et reporté chaque résultat sur les seuils de départ de la section suivante. Les deux dernières lignes ne sont pas des requêtes. Ce sont les plafonds définis dans notre configuration de scoring.

Quatre éléments de ce tableau méritent qu'on agisse.

• Les deux 100 n'ont pas les mêmes raisons. Les méthodes du nœud de sortie Tor sont tor_exit, datacenter_blocklisted, no_ptr_datacenter et known_spammer : un outil d'anonymisation avec un historique de spam. Celles du serveur Mullvad sont known_vpn_server, wireguard_open, datacenter_with_vpn_proxy et no_ptr_datacenter, avec threat.is_spammer à false et aucune entrée sur une liste de blocage DNS. Si vos clients utilisent des VPN, une règle de connexion qui transforme un blocage dû uniquement au VPN en MFA se défend, et elle ne se déclencherait jamais pour le nœud de sortie Tor.
• La ligne du milieu est celle où les seuils par action font leurs preuves. AhrefsBot à 35 passe la connexion, est signalé à l'inscription et part vers 3-D Secure au paiement. Pourtant, un robot d'exploration SEO vérifié n'a aucune raison de soumettre l'un de ces formulaires, ce que le score seul ne vous dit pas.
• Cette ligne du milieu a bougé en deux semaines. La même adresse a obtenu 23 le 8 octobre et 59, step_up, le 19 octobre avec abusive_listed parmi ses méthodes. Le 22 octobre, cette méthode avait disparu et le score était de 35, donc la connexion est passée de la MFA à une simple connexion. Nous examinons cette adresse en détail dans comment enquêter sur une adresse IP. Conservez le score, les méthodes et la date avec chaque décision, et relancez la requête avant d'agir sur un ancien verdict.
• Les adresses partagées ne peuvent pas atteindre block. Private Relay est plafonné à 60 (relay_max_score), il ne peut donc jamais franchir la ligne de blocage par défaut de 76. Le CGNAT est plafonné à 50 (cgnat_max_score), le haut de la tranche review. Notre ligne de blocage la plus stricte, 66 au paiement, se situe volontairement au-dessus des deux. À 60 ou moins, un utilisateur de relais plafonné pourrait être refusé pour avoir partagé une adresse.

Les deux lignes allow montrent que le scoring est additif. Le signal relay_ip du relais vaut 10 points à une confiance de 0,85, ce qui s'arrondit à 9. Le datacenter_ip du serveur Linode vaut 20 points à 0,5, soit 10. L'hébergement est une raison de regarder, pas de bloquer, et les relais doivent passer, comme nous l'expliquons dans comment détecter le trafic Private Relay et WARP.

Seuils de départ du score de fraude IP pour la connexion, l'inscription et le paiement

Les seuils de départ resserrent la ligne de blocage à mesure que le coût d'une autorisation à tort augmente : 76 à la connexion, 71 à l'inscription, 66 au paiement. Traitez-les comme des points de départ et ajustez-les sur vos propres données de fraude.

Combinez le score avec quelques règles sur les signaux pour les cas tranchés :

• Bloquez toute action lorsque detection.is_tor vaut true. C'est le seul cas où la raison à elle seule justifie un refus.
• Ne bloquez jamais strictement sur le score lorsque detection.is_relay ou threat.is_cgnat vaut true. Les plafonds l'imposent déjà ici ; la règle vous protège si quelqu'un abaisse une ligne de blocage plus tard.
• Au paiement, traitez review comme step_up. Notre tutoriel sur l'API de détection de fraude IP contient du code Node et Python testé pour exactement cette dérogation, ainsi qu'une gestion en mode dégradé lorsqu'une requête expire.

Pour voir ce que renvoie chaque type d'adresse à l'inscription, et les limites de vélocité par préfixe qui attrapent ce qu'un score laisse passer, lisez la détection des faux comptes à l'inscription.

Pour la signification de chaque tranche et la manière dont un score est construit, commencez par comment lire un score de fraude IP.

Un nœud de sortie Tor obtient 100, et les méthodes disent pourquoi

Voici une copie abrégée de la vraie réponse pour 185.220.101.1, interrogée à 04:56 UTC le 22 octobre 2026 :

Un fraud_score de 100 franchit toutes les lignes de blocage du tableau, donc la connexion, l'inscription et le paiement le refusent tous. Trois raisons suffisent à l'y amener : tor_exit (45 points à 0,99), known_spammer (40 à 0,9) et datacenter_blocklisted (30 à 0,75) totalisent 103 avant le plafond de 100. detection.is_vpn vaut false, car Tor est signalé à part, vous pouvez donc bloquer strictement detection.is_tor tout en soumettant les utilisateurs de VPN ordinaires à un simple défi.

La quatrième raison est une lacune de notre côté. no_ptr_datacenter indique que l'adresse n'a pas de DNS inverse, pourtant dig -x 185.220.101.1 a renvoyé un nom d'hôte de nœud de sortie Tor à 04:57 UTC ce matin-là. Il manque cet enregistrement dans notre base de données, et la correction est consignée. Le verdict tient grâce aux trois autres signaux, mais c'est une bonne raison d'écrire des règles sur des signaux auxquels vous faites confiance, et non sur le total brut.

Pourquoi un seuil global unique échoue

Un seuil unique échoue parce que chaque point d'entrée fait face à une attaque différente. Les pages de connexion absorbent le credential stuffing : le DBIR 2025 de Verizon a constaté qu'il représentait en médiane 19 % de toutes les tentatives d'authentification par jour, et 44 % le pire jour. Les paiements font face au test de cartes et les inscriptions aux faux comptes. Et le 2 décembre 2025, les humains n'ont généré que 47 % des requêtes HTML, selon le bilan annuel 2025 de Cloudflare Radar.

Les systèmes matures agissent déjà par tranches. Le score de bot de Cloudflare va de 1 à 99, et les clients écrivent des règles pour bloquer, mettre au défi ou autoriser selon ce score (scores de bot de Cloudflare). L'OWASP indique que le blocage d'IP « ne doit pas être utilisé comme défense unique ou principale en raison de la facilité à le contourner » (OWASP Credential Stuffing Cheat Sheet). La même page cite l'analyse de Microsoft selon laquelle la MFA aurait stoppé 99,9 % des compromissions de comptes. Cela fait de la tranche d'authentification renforcée à la connexion une assurance peu coûteuse. Le NIST SP 800-63B indique qu'une géolocalisation ou un bloc d'adresses IP inattendu « peut inciter à recourir à des contrôles supplémentaires basés sur le risque » et ne « remplace pas un facteur d'authentification » (NIST SP 800-63B).

GeoIPHub construit son score de risque explicable de 0 à 100 à partir de 36 raisons pondérées et nomme chacune de celles qui se sont déclenchées dans scoring.detection_methods. Certaines abaissent le score : une raison de FAI résidentiel retire 17 points (moins 20 à une confiance de 0,85) et un robot d'exploration vérifié 28,5 (moins 30 à 0,95).

Un seuil bas pénalise les adresses partagées et privées

Une ligne de blocage placée bas « par précaution » renvoie des clients qui partagent ou masquent leur adresse pour des raisons ordinaires :

• Les utilisateurs de VPN. Dans le rapport VPN 2026 de Security.org, une enquête menée en août 2026 auprès de 1 008 adultes américains, 42 % ont déclaré utiliser un VPN à des fins personnelles ou professionnelles. La confidentialité en général (56 %) et la sécurité en général (51 %) étaient les principales raisons.
• Le CGNAT. La RFC 6598 réserve 100.64.0.0/10 au CGNAT, et Cloudflare note que derrière lui « des centaines, voire des milliers de clients peuvent sembler provenir d'une seule adresse IP ». Cloudflare a aussi constaté que les IP CGNAT sont soumises à une limitation de débit trois fois plus souvent que les autres IP, alors que le taux médian de bots est presque identique : 4,8 % contre 4,7 % (Cloudflare sur le CGNAT).
• iCloud Private Relay. Cloudflare, qui exploite un saut du relais, indique que les sites qui utilisent les adresses IP pour la prévention de la fraude « peuvent faire confiance » aux connexions Private Relay, car Apple valide l'appareil et le compte (Cloudflare sur Private Relay).

GeoIPHub renvoie detection.is_mobile, detection.is_relay et threat.is_cgnat, et applique le plafond CGNAT de 50 et le plafond des relais de 60 avant de renvoyer le score.

Évaluez la bonne IP, sinon tous les seuils perdent leur sens

Si vous évaluez une valeur X-Forwarded-For usurpée, vos seuils soigneusement ajustés sont mis en échec avant même de s'appliquer. La RFC 7239 avertit que l'en-tête Forwarded « ne peut pas être considéré comme fiable », car n'importe quel nœud sur le chemin, y compris le client, peut le modifier (RFC 7239). La règle de MDN est que tout usage de sécurité de X-Forwarded-For « ne doit utiliser que les adresses IP ajoutées par un proxy de confiance », trouvées en remontant depuis l'entrée la plus à droite d'autant de positions que vous exploitez de proxys (MDN : X-Forwarded-For). Nous évaluons l'IP que vous nous envoyez, quelle qu'elle soit, donc déterminez-la d'abord à partir de votre chaîne de proxys de confiance.

Ajustez les seuils sur vos propres résultats

Partez du tableau, puis déplacez chaque ligne sur la base de preuves. Journalisez le score, recommended_action, detection_methods et la date pour chaque décision, et au bout de quelques semaines comparez-les avec les fraudes et rétrofacturations confirmées. Si votre ligne de paiement à 66 laisse passer des rétrofacturations entre 55 et 65, abaissez-la, mais pas à 60 ou moins tant que vous servez des utilisateurs de Private Relay. Si la vérification à l'inscription entre 51 et 70 attrape rarement un mauvais compte, relevez la ligne.

L'offre gratuite couvre 1 500 requêtes par jour avec tous les champs. Pour vérifier une adresse à la main, l'outil de vérification du score de fraude IP affiche le même score et les mêmes raisons, sans code.

Pour l'ensemble plus large des signaux, consultez nos guides sur la détection du trafic anonymisé sans bloquer de vrais clients, la fraude par proxy résidentiel et proxy de datacenter, la lutte contre la prise de contrôle de comptes et le credential stuffing, la détection des abus de promotions et de coupons à l'étape d'utilisation et la place des signaux IP dans une pile de détection de la fraude au paiement.

Questions fréquentes

Quel est un bon score de fraude IP à partir duquel bloquer ?

Il n'existe pas de seuil universel unique. Les tranches par défaut de GeoIPHub bloquent à partir de 76. Nos seuils de départ conservent cette valeur pour la connexion, l'abaissent à 71 pour l'inscription et à 66 pour le paiement, car une commande frauduleuse carte non présente coûte bien plus cher qu'une nouvelle demande de mot de passe. Les échelles des autres fournisseurs diffèrent, donc lisez tout seuil au regard des tranches de son propre fournisseur.

Que signifie un score de fraude IP de 75 ?

Sur l'échelle de 0 à 100 de GeoIPHub, 75 est le haut de la tranche step_up. Le blocage commence à 76. Soumettez-le à un défi plutôt que de l'autoriser silencieusement, et lisez scoring.detection_methods, car un 75 issu de signaux VPN et un 75 issu d'un historique de liste de blocage appellent des réponses différentes. Un vrai nœud de sortie Tor ne se situe pas du tout à 75 : 185.220.101.1 a obtenu 100, block, lors de notre requête du 22 octobre 2026.

Faut-il bloquer automatiquement les utilisateurs de VPN et de proxy ?

Non. Dans l'enquête de Security.org d'août 2026 auprès de 1 008 adultes américains, 42 % ont déclaré utiliser un VPN à des fins personnelles ou professionnelles, la confidentialité et la sécurité étant les principales raisons. Traitez un indicateur VPN comme un motif de défi d'authentification renforcée, pas de refus automatique, et réservez les blocages stricts aux nœuds de sortie Tor et aux adresses ayant un historique de spam ou de liste de blocage.

Un utilisateur d'iCloud Private Relay ou de CGNAT peut-il être bloqué sur le seul score ?

Pas avec les réglages par défaut de GeoIPHub. Les adresses Private Relay sont plafonnées à 60 et les adresses CGNAT (NAT de niveau opérateur) à 50, toutes deux sous la ligne de blocage par défaut de 76. Gardez chaque seuil de blocage au-dessus de 60, et une adresse partagée ne pourra jamais qu'être soumise à un défi, jamais refusée, sur le seul score.

Pourquoi le seuil de blocage est-il plus bas au paiement qu'à la connexion ?

Une autorisation à tort au paiement expédie des marchandises payées avec une carte volée et revient sous forme de rétrofacturation, tandis qu'une autorisation à tort à la connexion doit encore passer le mot de passe et un éventuel second facteur. Le paiement bloque donc à partir de 66, et la connexion seulement à partir de 76.