Propagation de la liste de blocage : Éliminer la menace à la source (FR)

Il y a un moment précis où la plupart des programmes de lutte contre les abus perdent de la valeur : le moment qui suit votre victoire.

Votre couche de trafic signale un compte. Un analyste enquête. Les preuves sont solides, le cas est confirmé, le compte est banni. Et puis, quelques heures plus tard, le même opérateur est de retour sur de nouveaux comptes, car la seule chose que votre application a touchée était une ligne dans une table d'utilisateurs.

Anthropic a décrit exactement cette dynamique dans son rapport de février 2026 sur les campagnes de distillation – un réseau proxy qui « gérait simultanément plus de 20 000 comptes frauduleux », les remplaçant au fur et à mesure de leur suppression. La suppression n'était pas le goulot d'étranglement. La régénération était moins chère que la suppression.

La solution consiste à faire en sorte que l'application opère sur les identifiants plutôt que sur les comptes. L'API Listes de Didit est conçue autour d'un mécanisme qui le fait en un seul appel.

Points clés à retenir

• L'ajout à la liste de blocage avec reference_session_id permet à Didit d'extraire automatiquement la bonne valeur de la session — visage, document, téléphone, e-mail, IP ou appareil — de marquer le modèle sous-jacent comme bloqué et de lier l'entrée à la session source.
• 12 types d'entrée : face, document, phone, email, ip_address, device_fingerprint, wallet_address, bank_account, user, business, country, key.
• Les listes de blocage sont créées par le système, une par type d'entrée, et immuables. Vous ne pouvez pas les créer, ce qui assure une application uniforme.
• Les entrées prennent effet immédiatement au moment de la vérification. La suppression d'une entrée débloque la correspondance.
• ip_address accepte une plage CIDR, vous pouvez donc bloquer l'infrastructure plutôt qu'une seule adresse.
• Les listes d'autorisation pour les mêmes 12 types d'entrée maintiennent les développeurs de confiance en dehors de tout chemin d'escalade.

Les deux types de listes qui comptent

L'API comporte trois types de listes, et leur distinction est délibérée.

Les listes de blocage sont créées par le système — une par type d'entrée — et sont immuables. Vous ne pouvez pas les créer, les renommer ou les supprimer. Vous ajoutez et supprimez des entrées. Cette contrainte est une caractéristique : elle signifie que « bloqué » a exactement une seule signification au sein de votre organisation, et qu'il n'y a aucun moyen de se retrouver avec quatre listes de blocage de visages concurrentes que différents services vérifient de manière incohérente.

Les listes d'autorisation sont à créer par vous. Les appareils connus comme fiables, les plages d'adresses, les entités commerciales et les utilisateurs y sont ajoutés.

Les listes personnalisées sont pour tout le reste — vos propres taxonomies, groupes de surveillance, cohortes de révision.

# Trouver la liste de blocage des visages
curl -X GET 'https://verification.didit.me/v3/lists/?list_type=blocklist&entry_type=face' \
  -H 'x-api-key: YOUR_API_KEY'

Le mécanisme qui compte

Voici la manière ordinaire de bloquer quelque chose, et c'est la mauvaise manière dans presque toutes les situations réelles :

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "value": "203.0.113.44" }'

Cela bloque une adresse. Pendant ce temps, la session que vous enquêtiez contenait également un visage, un numéro de document, un téléphone, un e-mail et une empreinte d'appareil — chacun d'eux étant un identifiant que l'opérateur doit remplacer avant de revenir.

Le meilleur appel :

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "reference_session_id": "a7f3...c19" }'

Passez reference_session_id et Didit extrait automatiquement la bonne valeur pour le type d'entrée de cette liste de la session, marque le modèle sous-jacent comme bloqué et lie l'entrée à la session afin que la console puisse vous montrer d'où elle provient.

Trois choses en découlent, et toutes les trois sont importantes sur le plan opérationnel :

Pas d'extraction manuelle. Votre analyste ne lit pas une empreinte d'appareil sur un écran pour la retaper. Les erreurs de transcription dans les données d'application sont des échecs silencieux — le bannissement ne se déclenche tout simplement pas, et personne ne le découvre.

La provenance est préservée. Chaque entrée renvoie à la session qui l'a justifiée. Lorsque quelqu'un demande dans quatre mois pourquoi cet appareil est bloqué, la réponse est en un clic, et non un projet d'archéologie.

L'application est reproductible. Le même appel contre chaque liste de blocage par type d'entrée couvre toute la surface d'identifiants de la session.

Si une session contient plusieurs instances du même type, passez value en même temps que reference_session_id pour lever l'ambiguïté.

Vous pouvez également appliquer la règle en dehors d'une session de vérification. reference_object_uuid, associé à metadata.reference_type — transaction, vendor_user ou vendor_business — permet de bloquer à partir d'une transaction ou d'un utilisateur ou d'une entreprise tiers, et de maintenir le même lien vers la source.

Les 12 types d'entrée

Type d'entrée	Bloque	Notes
face	La personne	Peut également être téléchargé directement via le téléchargement de visage
document	L'identifiant
phone	Le numéro	Normalisé automatiquement en E.164
email	L'adresse
ip_address	L'adresse ou la plage	Accepte le CIDR, par exemple 10.0.0.0/8
device_fingerprint	La machine	Minimum 8 caractères alphanumériques
wallet_address	L'adresse on-chain
bank_account	Le compte
user	L'enregistrement utilisateur
business	L'entité
country	La juridiction
key	Une clé personnalisée

Deux d'entre eux méritent d'être soulignés pour ce problème.

ip_address accepte une plage CIDR. Bloquer 203.0.113.0/24 bloque l'infrastructure, et non une seule adresse. Lorsqu'une opération de farming s'exécute sur un sous-réseau loué, c'est la différence entre une application qui s'adapte et une application qui joue au jeu du tape-taupe. Utilisez-la avec prudence — une plage couvre également de vrais utilisateurs, et des plages trop larges sont la façon dont vous bannissez discrètement l'opérateur mobile d'un pays.

face prend en charge le téléchargement direct. Lorsque vous avez une image mais pas de session, chargez-la directement :

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/face-upload/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "image": "<base64-encoded image>" }'

Didit extrait la biométrie. Dès lors, ce visage est vérifié à chaque vérification.

Ce qui se passe après l'ajout d'une entrée

L'ajout à une liste de blocage système bloque immédiatement les correspondances futures au moment de la vérification. Il n'y a pas de délai de propagation ni de tâche par lot.

Lors de la prochaine vérification, l'application se manifeste par des avertissements :

• FACE_IN_BLOCKLIST — correspondance définitive, vérification refusée. POSSIBLE_FACE_IN_BLOCKLIST est une correspondance limite en dessous du seuil strict et devrait être acheminée pour examen, et non refusée.
• IP_ADDRESS_IN_BLOCKLIST / DEVICE_FINGERPRINT_IN_BLOCKLIST — détections de réseau et d'appareil.

Dans la recherche de visage, une correspondance de liste de blocage est la seule chose qui définit le status à "Declined". Chaque correspondance dans la réponse porte également is_blocklisted, de sorte qu'une enquête vous montre immédiatement quelles parties d'un cluster sont déjà sous application et lesquelles sont toujours actives.

La suppression est symétrique : la suppression d'une entrée débloque l'entité correspondante. L'application est réversible par conception, ce qui est important car une application trop large est un risque réel et vous avez besoin d'un chemin de retour clair.

curl -X DELETE 'https://verification.didit.me/v3/lists/{list_uuid}/entries/{entry_uuid}/' \
  -H 'x-api-key: YOUR_API_KEY'

Listes d'autorisation : protéger les développeurs que vous souhaitez

Une application qui ne fait qu'escalader finit par étrangler le produit. Les mêmes 12 types d'entrée prennent en charge les listes d'autorisation, et elles sont la soupape de décharge.

Ajoutez à la liste d'autorisation les plages IP des bureaux d'un partenaire de conception. Ajoutez à la liste d'autorisation les appareils de l'équipe d'ingénierie d'un client d'entreprise. Ajoutez à la liste d'autorisation une entité commerciale vérifiée afin que ses utilisateurs n'atteignent jamais un chemin d'escalade. IP_ADDRESS_IN_ALLOWLIST et DEVICE_FINGERPRINT_IN_ALLOWLIST se déclenchent lorsqu'une correspondance se produit, afin que vous puissiez confirmer que l'exemption a été appliquée plutôt que de supposer qu'elle l'a été.

C'est le mécanisme qui rend une application agressive supportable. Vous pouvez vous permettre une politique stricte sur les infrastructures inconnues précisément parce que votre population de confiance est explicitement exclue.

Erreurs à gérer

• 400 — la valeur n'a pas passé le validateur du type d'entrée, le list_type est incorrect pour l'opération (par exemple, un téléchargement de visage vers une liste non-visage), ou reference_session_id ne contient aucune donnée du type demandé. Ce dernier cas est courant et bénin : toutes les sessions ne capturent pas tous les identifiants.
• 403 — {"detail": "Vous n'avez pas la permission d'effectuer cette action."}

Notez qu'une erreur 400 du type « la session ne contient pas de données de ce type » est attendue lorsque vous parcourez une session sur toutes les listes de blocage par type d'entrée. Traitez-la comme un saut, pas comme un échec.

Un flux d'application travaillé

Un analyste a confirmé un abus sur le compte acct_8842.

1. Résolvez d'abord le cluster. La recherche de visage sur le visage de la session renvoie douze comptes ; la corrélation d'appareils et d'IP en ajoute une douzaine. Une application avant la résolution bannit un compte et avertit l'opérateur.
2. Ajoutez à la liste de blocage à partir de la session confirmée — reference_session_id contre les listes de blocage de visage, d'appareil, d'IP, d'e-mail, de téléphone et de document. Six appels, aucune extraction manuelle, provenance complète.
3. Considérez la plage. Si les preuves réseau indiquent une infrastructure louée, une entrée CIDR couvre le sous-réseau. Vérifiez d'abord ce qui s'y trouve d'autre.
4. Agissez sur le cluster conformément à votre propre politique — les comptes que vous avez déjà identifiés ne se débloquent pas d'eux-mêmes.
5. Vérifiez l'application. Relancez la recherche de visage. Les correspondances devraient maintenant porter is_blocklisted: true.
6. Attendez la tentative de régénération. Le prochain compte créé sur ce visage, cet appareil ou ce sous-réseau sera refusé à la vérification au lieu d'apparaître dans votre trafic trois semaines plus tard.

L'étape 6 est le point crucial. Le coût de retour de l'opérateur n'est plus « créer une nouvelle adresse e-mail ». C'est « acquérir un nouveau matériel, un nouveau réseau et une nouvelle personne ».

Cas d'utilisation

Plateformes d'API d'IA convertissant un cas de distillation ou d'abus confirmé en application sur chaque identifiant touché par l'opérateur.

Abus d'essai et de crédit où le même appareil et le même visage reviennent constamment pour une nouvelle allocation gratuite.

Places de marché bloquant les vendeurs supprimés de se réinscrire sous une nouvelle entreprise.

iGaming appliquant l'auto-exclusion, où un joueur exclu qui revient est un échec réglementaire et où l'application au niveau du visage est le seul contrôle fiable.

Foire aux questions

Puis-je créer ma propre liste de blocage ?

Non. Les listes de blocage sont créées par le système, une par type d'entrée, et sont immuables — vous ajoutez et supprimez des entrées. Vous pouvez créer librement des listes d'autorisation et des listes personnalisées. Cette contrainte maintient la signification unique de « bloqué » partout.

À quelle vitesse une entrée prend-elle effet ?

Immédiatement, lors de la prochaine vérification.

Que se passe-t-il si je bloque quelque chose par erreur ?

Supprimez l'entrée et l'entité est débloquée. C'est pourquoi la provenance est importante — chaque entrée créée à partir d'une session y est liée, de sorte que vous pouvez vérifier la raison d'une entrée avant de la supprimer.

Le blocage d'une plage IP affecte-t-il les utilisateurs légitimes de cette plage ?

Oui, et c'est le risque. Une entrée CIDR bloque tout ce qu'elle contient. Utilisez les plages lorsque les preuves indiquent une infrastructure dédiée, utilisez des adresses uniques autrement, et ajoutez d'abord les plages connues comme fiables à la liste d'autorisation.

Puis-je bloquer à partir de quelque chose qui n'est pas une session de vérification ?

Oui. reference_object_uuid plus metadata.reference_type (transaction, vendor_user ou vendor_business) couvre les transactions et les utilisateurs ou entreprises tiers.

Cela empêche-t-il l'extraction de modèles ?

Non. Cela empêche un acteur connu spécifique de se réintroduire via les identifiants contre lesquels vous avez appliqué la règle, et cela augmente le coût de la régénération. La détection de l'extraction est le travail de votre couche de trafic, et la limitation de ce que l'extraction produit est le travail de votre couche de modèle. C'est le bras d'application d'une défense à trois couches, et non un remplacement des deux autres.

Prêt à commencer ?

L'API Listes est disponible sur chaque compte Didit.

• Lisez la documentation — Présentation de l'API Listes et le catalogue d'avertissements IP et d'appareils.
• Découvrez le produit — Vérification d'identité.
• Consultez les tarifs — publiés, paiement à l'utilisation réussie, sans minimum.
• Commencez gratuitement — business.didit.me, 500 vérifications KYC par mois sans frais.