Risk Engine adaptative

Le risk score est la somme pondérée de toutes les pénalités (0-100). Les seuils sont déterminés par le profil de site et la politique de formulaire actifs. La réponse V2 contient en plus un Confidence Score (0.0-1.0) et des reason codes lisibles par machine.

Score	Action	Signification
0-29	allow	Humain, laisser passer
30-59	challenge	Suspicion : laissé passer mais consigné
60-100	block	Bot détecté, blocage

Facteurs de pénalité

pow_failed:          +100   PoW falsch oder fehlend
nonce_reused:        +100   Replay-Angriff
ip_blocked:          +100   IP auf Blockliste
rate_limit_hit:       +80   Zu viele Requests
user_agent_headless:  +70   Puppeteer/Playwright
tor_exit:             +60   TOR Exit Node
behavior_bot:         +50   Verhalten bot-typisch
time_too_fast:        +35   Submit < 1.5 Sekunden
asn_hosting:          +25   Rechenzentrum-ASN
behavior_suspicious:  +20   Verhalten verdächtig

V2.1 Advanced Bot Detection

Des signaux supplémentaires qui démasquent même les navigateurs headless camouflés. Toutes les vérifications sont sensibles au contexte : les appareils mobiles et les navigateurs axés sur la confidentialité (Safari/Firefox) sont correctement reconnus comme légitimes et ne sont pas signalés à tort.

env_automation_globals: +90   Selenium/Puppeteer/CDP Leak im window-Objekt
env_ua_brand_bot:       +80   UA Client Hints verraten Automation-Framework
env_software_renderer:  +50   WebGL nutzt SwiftShader/llvmpipe = headless
env_canvas_too_fast:    +40   Canvas-Render < 2ms = headless (Mensch: 5-50ms)
env_no_storage:         +30   localStorage UND indexedDB fehlen
env_raf_robotic:        +25   requestAnimationFrame perfekt uniform (CV < 0.05)
env_no_webgl_ext:       +25   0 WebGL-Extensions auf Desktop = headless
header_no_sec_fetch:    +25   Sec-Fetch-* Header fehlen = altes/scripted Client
header_no_accept_lang:  +20   Accept-Language fehlt = scripted
env_no_hover:           +5    Hover nicht unterstützt (selten valide auf Desktop)
env_audio_hash_missing: +5    OfflineAudioContext blockiert (Privacy-Browser ok)

V2.1 augmente nettement le taux de détection des frameworks furtifs (Playwright Stealth, Puppeteer Stealth), sans pénaliser les utilisateurs légitimes.

Profils de site & policies de formulaire

La Risk Engine V2 évalue selon le contexte : les formulaires de connexion sont jugés plus sévèrement que les formulaires de contact. Les profils de site définissent la posture de base, les politiques de formulaire la surchargent de façon ciblée par type de formulaire.

Profils de site (presets)

Chaque site est associé à un profil. Le profil détermine les seuils, les types de challenge et les pondérations comportementales.

Profil	Allow <	Challenge <	Difficulty	Utilisation
Low Friction	40	70	2	Newsletter, commentaires, pages d'information
Balanced	30	60	4	Standard pour la plupart des formulaires
Auth Hardened	20	50	5	Connexion, inscription, réinitialisation de mot de passe
High Security	15	40	6	Checkout, actions admin, paiement

Politiques de formulaire

Les politiques de formulaire surchargent le profil de site pour certains types de formulaires. Le form_type est transmis lors de la requête de vérification.

form_type	Profil	Allow <	Challenge <	Mode de défaillance
login	Auth Hardened	20	50	fail_closed
register	Auth Hardened	20	50	fail_closed
password_reset	High Security	15	40	fail_closed
checkout	High Security	15	40	fail_closed
contact	Balanced	30	60	fail_open
comment	Low Friction	35	65	fail_open
newsletter	Low Friction	40	70	fail_open

Ordre de fusion

Les niveaux ultérieurs remplacent les précédents :

1. Globale Defaults     (config: allow<30, challenge<60)
2. Site-Profil           (z.B. "Auth Hardened" → allow<20, challenge<50)
3. Form-Policy           (z.B. login → allow<15, fail_closed)

Intégration (développeurs)

Le form_type est indiqué lors de l'intégration du widget et de la requête de vérification :

<!-- Widget: form_type als data-Attribut -->
<form data-captchacore="interactive" data-form-type="login">
    <div data-captchacore-widget data-form-type="login"></div>
</form>

// Verify-Request: form_type im Body
POST /api/v2/verify
{
    "token":     "...",
    "form_type": "login"   // Steuert welche Policy angewendet wird
}

Types disponibles : login, register, contact, comment, checkout, password_reset, newsletter, custom. Sans form_type, les valeurs par défaut globales sont utilisées.

Under-Attack-Mode

En cas d'attaque (taux de blocage élevé), la protection peut être renforcée :

Activation automatique

Si plus de 70 % de toutes les requêtes sont bloquées dans une fenêtre de 5 minutes, l'UAM s'active automatiquement.

# Konfigurierbar in den globalen Einstellungen
uam.auto_threshold:        0.70     # 70% Block-Rate
uam.window_minutes:        5
uam.auto_deactivate_after: 3600     # 1 Stunde
uam.cookie_ttl_minutes:    30

En UAM, la difficulté du PoW augmente d'un niveau. Les visiteurs vérifiés reçoivent un cookie d'accès signé HMAC (HttpOnly, SameSite=Strict).

Détection