API Bot Protection et antifrode

1) Pourquoi est-ce nécessaire

Les bots et les attaquants attaquent les points d'entrée de la croissance et de l'argent : enregistrement, login (ATO), dépôts/conclusions, mécanique promotionnelle, catalogues de jeux/ratios. Les règles manuelles et le taux limite net sont déjà insuffisants : il faut des signaux à plusieurs niveaux, un scoring en temps réel et un contrôle de la solution (allow/deny/challenge/throttle) avec des commentaires sur les événements commerciaux (chargbacks, chargeback-ratio, KYC-feels).

2) Taxonomie des menaces

Inscription/onbording : comptes de masse, e-mails jetables/banques SIM, fermes de devis.
ATO (Account Takeover): credential stuffing, password spraying, session hijack.
Bonus-abyuz : multiaccouting, arbitrage géo/juridictions, contournement self-exclusion.
Karting/paiement frod : test de carte, portefeuille volé, remboursements.
Scraping/inventaire : traction agressive de contenu, prix, coefficients.
API-DoS de faible intensité : attaques de tortues, slow-POST, émulation de SDK mobiles.
Webhooks/intégration : falsification des notifications sans HMAC/mTLS, replay.

3) Architecture de protection

3. 1 Calques

1. Edge (CDN/WAF/passerelle) : échecs précoces (réputation ASN/Geo/IP), challenges légers, limites, PoW.
2. Risk API (PDP par risque) : moteur centralisé de règles/ML ; ответ — `decision`, `score`, `reason`, `ttl`.
3. Niveau app : invariants de domaine, logique d'entreprise (limites, KYC, AML), rhubarbe asynchrone.
4. Flux d'événements : Kafka/Kinesis → feature store/model → feedback des paiements/disputes.

3. 2 Contour de la solution

[Request] → Edge Plugins → (enrich) → Risk API (rules+ML) → Decision:
allow      deny      throttle      challenge(type=captcha    sms    PoW    biometry)

La solution est mise en cache par clé (par exemple, device × account × route) pendant "ttl'secondes.

4) Signaux et enrichissement

Réseau/canal : IP/ASN, proxy/VPN/Tor, rdns, rtt/jitter, SYN-rate, TLS-fingerprint (JA3/JA4), comportement HTTP/2/3.
Device/browser : canvas/audio/WebGL FP (avec soin), plate-forme/SDK, timezone/locale, résolution, polices, indicateurs WebDriver/headless, attraction mobile (SafetyNet/DeviceCheck, si possible).
Comportement : vitesse d'entrée, trajectoires souris/tache, séquence d'écrans, dwell-time, taux de tentative, transitions entre les identifiants du navigateur.
Contenu/demande : formulaire e-mail/domaine, fournisseurs disponibles, téléphone HLR/ou type de numéro, carte BIN, compte/IBAN dans les registres sank, similitudes de nom/adresse.
Compte/historique : âge du compte, statut KYC, rétention, ARPPU, velocity sur les dépôts/retraits/bonus.
Sources externes : listes de compromis (HIBP-like), signaux de risque de paiement (PSP), réputation ASN.

5) Solution : Règles + ML

5. 1 Règles (déterministes)

Velocity : « N inscriptions avec/24 en 10 min », « M logins avec un devis X comptes », « K 3DS-feels consécutifs ».
Géo/juridiction : conflits IP-géo vs adresse/document, sauts soudains de localisation.
Invariants d'affaires : limites des paiements responsables, self-exclusion, listes de sanctions.

5. 2 ML-scoring (real-time)

Modèle léger (GBM/logreg) sur les traits en ligne : 'ip _ risk', 'device _ age', 'account _ age', 'pwd _ fail _ rate', 'bin _ risk', 'velocity _', 'behavioral _'.
Un modèle distinct pour l'ATO et un modèle distinct pour les paiements/retraits.
Segmentation par juridiction/tenant (étalonnage des seuils par marché).

5. 3 Prise de décision

if ip_blacklisted or bad_asn then deny else if rule_severe then challenge(hard)
else if score >= 0. 9 then deny else if 0. 7 <= score < 0. 9 then challenge(soft)
else allow

Dans « challenge », stocker les faits de passage/échec ; escalader/réduire les frottements dynamiquement.

6) Velocity et quotas (clés et fenêtres)

Ключи: `ip`, `ip/24`, `device_id`, `account_id`, `payment_instrument`, `email_domain`, `bin`.
Fenêtres : coulissantes (1m/5m/1h/24h) + séparées « burst « /« sustained ».
Politiques : « dur » deny sur les itinéraires chauds (login/dépôt), doux throttle sur le contenu.

pseudo allow, retry_after = gcra_allow(key="login:ip:"+ip, rate=60/min, burst=30)
if not allow:
return 429, {"Retry-After": retry_after}

7) Challenges et vérification de « l'humanité »

CAPTCHA/turnstile: как soft-challenge; nettoyer après une grande confiance dans la session « propre ».
Proof-of-Work (PoW) : pour les API/scripts, calculer un hachage avec une complexité donnée ; complexité dynamique lorsque la charge augmente.
OTP/SMS/Email/Push : pour les opérations ATF/critiques ; ne pas abuser (coût/UX).
WebAuthn/biométrie : haut niveau de confiance sur les détails cash-out/changement payout.
Device trust : compte bind du device vérifié ; nouveaux devis → challenge.

8) Intégration dans la passerelle/proxy

8. 1 Envoy : ext_authz → l'API Risk (pseudo)

yaml http_filters:
- name: envoy. filters. http. ext_authz typed_config:
http_service:
server_uri: { uri: http://risk-api:8080, cluster: risk, timeout: 80ms }
authorization_request:
allowed_headers:
patterns:
- exact: "x-tenant"
- exact: "x-device-id"
- exact: "user-agent"
authorization_response:
allowed_upstream_headers:
patterns: [{ exact: "x-risk-score" }, { exact: "x-risk-decision" }]
- name: envoy. filters. http. router

8. 2 NGINX/Lua : PoW léger et velocity

nginx lua_shared_dict vel 20m;

access_by_lua_block {
local ip = ngx. var. remote_addr if not gcra_allow("reg:ip:"..ip, 20, 40) then ngx. header["Retry-After"] = 30; return ngx. exit(429)
end

local pow = ngx. req. get_headers()["X-POW"]
if not verify_pow(pow, ngx. var. request_id, 18) then ngx. status = 401; ngx. say('need-pow'); return ngx. exit(401)
end
}

9) Le contrat de Risk API

json
{
"tenant":"eu-1",
"route":"POST /v1/login",
"subject":{"account_id":"a123","email":"u@d. com"},
"device":{"id":"d-xyz","fp":"...","ja3":"...","headless":false},
"network":{"ip":"203. 0. 113. 10","asn":12345,"country":"DE","rtt_ms":42},
"context":{"fail_5m":3,"pwd_reset_24h":1}
}

json
{ "decision":"challenge", "score":0. 83, "reason":"high_velocity+new_device", "ttl_sec":900, "challenge":"captcha" }

10) Données, fiches et modèles

Feature Store (en ligne) : Redis/Scylla/KeyDB - compteurs/velocity/horodatages.
Batch/hors ligne : DWH (BigQuery/S3 + Athena) pour la formation/refits ; stocker les marques de sortie, chargeback, rhubarbe manuel.
Modèles : simples pour le temps réel (logreg/GBM) ; lourd (XGBoost/NN) - hors ligne avec PGMs/échelle et distillation ultérieure.
Contrôle de la dérive : PSI, ASC/PR, calibrage des seuils par région/canal.

11) Observation et contour opérationnel

• `risk_requests_total{route,decision}`
• `risk_score_bucket` (distribution)
• `waf_block_total`, `velocity_block_total`, `challenge_pass_rate`
• `ato_incidents`, `carding_detected`, `cashout_denied`
• métriques d'entreprise : 'chargeback _ rate', 'bonus _ abuse _ rate', 'false _ positive _ rate'
• Logs (édités) : 'decision', 'score', signaux clés, 'trace _ id', sans PII/secrets.
• A/B et Shadow : nouvelle politique en mode shadow (nous logions les solutions), puis canary (1-5 %), autorollbek par SLO/FP.
• Playbooks : escalade, resserrement temporaire, retour en arrière, « patchs virtuels ».

12) Confidentialité et conformité

Minimiser le PII ; hachez les identifiants résistants (par exemple, email SHA-256 avec sel).
Respecter la juridiction régionale (localisation des données, consentement).
Explications transparentes des solutions de rhubarbe manuel ; ne stocker que le nécessaire et avec la TTL.

13) Spécificités d'iGaming/Finance

Inscription : filtres e-mail disponibles/VoIP, velocity par/24, device-farm → challenge/deny.
Login/ATF : nouveaux devis/géo-sauts → OTP/WebAuthn ; password spraying → throttle/deny.
Bonus : limites sur le « chemin de blanchiment » (depozit→bonus→minimalnyy oborot→vyvod), analyse graphique de l'affiliation (adresses/devis/cartes).
Paiements/conclusions : risque BIN, country-mismatch, signaux PSP ; cashout sur le nouvel outil → le seuil élevé et le chekap KYC.
Вебхуки PSP/KYC : HMAC + mTLS, étroit l'IP-allow-feuille, anti-replay (' X-Timestamp ', la fenêtre ±5 des mines).

14) Anti-modèles

Un captcha universel « partout et toujours » → un FP/baisse de conversion élevé.
Seulement rate limit sans signaux comportementaux/device.
Stockage des empreintes « brutes » et PII indéfiniment.
Pas de shadow et de canary pour les nouvelles politiques.
Confiance totale dans les marques de « réputation » extérieures sans validation propre.
Prise de décision sur le client (JS/SDK mobile) sans vérification du serveur.

15) Exemples de règles et pseudo-code

15. 1 Règle composite (temps réel)

pseudo score = 0 if ip_asn in bad_asn_list then score += 0. 5 if device_age < 1d and route in {login, withdraw} then score += 0. 3 if velocity("login:account", 5m) > 10 then score += 0. 3 if geovelocity(last_login_loc, current_loc) > 800km/h then score += 0. 2 decision = score>=0. 9? "deny": score>=0. 7? "challenge": "allow"

15. 2 Graphe des liens (multi-account)

edge(accountA, deviceX)
edge(accountB, deviceX)
edge(accountB, cardY)
edge(accountC, cardY)
Threshold by common nodes → investigation/deny bonus

16) Chèque-liste prod-prêt

• Architecture hiérarchisée : Edge → Risk API → App, flux d'événements.
• Signaux : réseau, device, comportement, contenu, paiement ; minimisation des IPI.
• Velocity/GCRA sur les clés ip/device/account/payment, fenêtres coulissantes.
• Décisions : allow/deny/challenge/throttle ; Cache de solution avec TTL ; entrepôt de faits Challenges.
• Challenges : captcha/PoW/OTP/WebAuthn ; complexité dynamique.
• API de risque : SLA <100ms, cache, dégradation en mode « minimum sûr ».
• Observabilité : métriques de risque, FP/FN, dashboards, alertes ; métriques d'entreprise (chargeback/bonus-abuse).
• Shadow → canary → enforce; les pleybooks de l'escalade et du recul.
• PSP/KYC Webhooks : HMAC + mTLS + anti-replay + allow-list.
• Exigences régionales et TTL sur les données sensibles.

17) TL; DR

Construisez une protection en couches : filtres edge et challenges, API Risk centralisée avec règles + ML et flux d'événements pour la rétroaction. Utilisez les limites velocity, les signaux réseau/device/comportement, le challenge dynamique (captcha/PoW/OTP/WebAuthn). Prendre des décisions allow/deny/challenge/throttle, mesurer les FP/FN et l'effet d'entreprise, dérouler via shadow/canary. Pour les chemins de paiement/bonus - des profils serrés distincts et un lien avec KYC/AML.