API de score de fraude : IP, e-mail et téléphone
Une API de score de fraude pour les données d’IP, d’e-mail et de téléphone combine plusieurs signaux de risque indépendants en un seul nombre, afin de prendre une seule décision au lieu de jongler avec quatre contrôles séparés. Le score de fraude d’ipto prend une adresse IP, un e-mail, un numéro de téléphone et un User-Agent, et renvoie un score de 0 à 100 avec le détail des contributions.
La raison de fusionner les signaux est que chacun est faible isolément. Une adresse VPN est normale pour de nombreux utilisateurs honnêtes. Un e-mail jetable peut simplement être celui d’une personne qui protège sa boîte de réception. Un User-Agent de type bot peut être un outil de supervision. Ensemble, en revanche, une sortie Tor, un domaine d’e-mail jetable et un User-Agent d’automatisation sur une même inscription forment une combinaison inhabituelle, et un score combiné la fait ressortir.
Ce qui entre dans le score
Chaque entrée est notée par l’outil ipto correspondant, et les résultats sont mélangés avec des pondérations fixes. L’IP compte pour 40 pour cent et l’e-mail, le téléphone et le User-Agent comptent chacun pour 20 pour cent. La logique de chaque composante est volontairement simple et inspectable :
- IP. Fondée sur le score d’abus corroboré lorsqu’il existe ; sinon une sortie Tor obtient un score élevé, une adresse VPN un score modéré et une adresse sans indicateur un score bas. Vous pouvez explorer ces entrées avec le vérificateur de VPN, Tor et proxy et le vérificateur d’abus d’IP.
- E-mail. Une syntaxe invalide obtient un score élevé, un domaine jetable un score élevé, un domaine sans enregistrement MX fonctionnel un score intermédiaire, et une adresse bien formée sur un domaine normal un score bas. C’est la même logique que celle du vérificateur d’e-mail.
- Téléphone. Un numéro qui échoue à la validation du plan de numérotation obtient un score élevé, un numéro valide un score bas. Comme le vérificateur de téléphone utilise un parseur auto-hébergé sans recherche d’opérateur en direct, il s’agit d’un contrôle de vraisemblance, pas d’une preuve que le numéro est actif.
- User-Agent. Un client qui est analysé comme un bot ou un robot d’indexation obtient un score élevé ; un navigateur ordinaire un score bas, avec la même analyse que le parseur de User-Agent.
La réponse liste chaque signal avec son propre score et les champs bruts qui le sous-tendent, comme is_vpn, is_tor, risk_tier, has_mx, disposable et is_bot. Cela rend le nombre explicable : lorsqu’un utilisateur est signalé, vous pouvez dire exactement pourquoi.
Comment les entrées manquantes sont gérées
Le trafic réel est incomplet. Une tentative de connexion peut avoir une IP et un User-Agent mais pas d’e-mail, et un formulaire d’inscription peut omettre le champ du téléphone. Le score de fraude ne traite pas une entrée absente comme « propre ». Les signaux manquants sont écartés, et le poids des signaux que vous avez fournis est redimensionné pour que leur somme couvre l’ensemble du score.
Concrètement, si vous n’envoyez qu’une IP, elle porte tout le poids ; une sortie Tor produit donc un score élevé au lieu d’être diluée vers le sûr par trois champs vides. Si vous envoyez une IP et un e-mail, les poids deviennent environ deux tiers et un tiers. Deux limites méritent d’être connues. Si aucune entrée ne se résout, le score retombe sur une base basse. Et le signal d’IP ne couvre actuellement que l’IPv4, car les données de menaces pour l’IPv6 ne sont pas disponibles sous la même forme ; une adresse IPv6 est ignorée plutôt que notée comme propre, associez-la donc aux autres entrées.
Du score à l’action
Le score correspond à un niveau de risque : en dessous de 20, faible ; de 20 à 44, moyen ; de 45 à 69, élevé ; et 70 ou plus, critique. Considérez-les comme un a priori qui indique où appliquer de la friction. Un schéma raisonnable consiste à autoriser les scores faibles, à demander un second facteur ou une confirmation par e-mail pour les niveaux moyen et élevé, et à placer les scores critiques en file d’examen. L’outil n’est pas destiné à être l’unique fondement d’un refus à un client, et il ne remplace pas vos propres signaux comme l’historique de commandes, l’historique d’appareils ou les enregistrements de rétrofacturation, qu’ipto ne collecte pas.
L’essayer
Le moyen le plus rapide de voir le comportement est le vérificateur de score de fraude : remplissez un champ, notez le score, puis ajoutez les autres et observez le détail changer. La même capacité est disponible via l’API, documentée dans la documentation de l’API, les quatre entrées étant facultatives. L’exécuter sur un échantillon de vos propres inscriptions récentes est un bon moyen d’apprendre quel signal porte le risque dans votre trafic, et le raisonnement derrière la composante IP est détaillé dans le scoring de réputation d’IP expliqué.