Bot Protection

Wocha provides market-leading bot protection through a multi-layered approach that combines device fingerprinting, CAPTCHA challenges, Proof-of-Work puzzles, and adaptive MFA — all orchestrated by an intelligent challenge system that minimises friction for legitimate users.

Architecture

Bot protection operates at two enforcement points:

1. Login-time bot gate — A lightweight check that runs before credential processing. High-confidence bot requests (bot_score >= 0.8) are blocked immediately unless a valid Turnstile token is present.

2. Consent-time risk scoring — The full 18-assessor risk engine evaluates the request and the challenge orchestrator selects the appropriate challenge type from a graduated ladder.

Challenge Ladder

When the risk engine determines a challenge is needed, it selects from five tiers of escalating friction:

Cloudflare Turnstile

Wocha integrates natively with Cloudflare Turnstile for invisible CAPTCHA challenges.

Configuration

Set the following environment variables in your auth service:

NEXT_PUBLIC_TURNSTILE_SITE_KEY=0x4AAAAAAA...
TURNSTILE_SECRET_KEY=0x4AAAAAAA...
TURNSTILE_MODE=invisible  # invisible | managed | off

Or configure via the Console under Security > Attack Protection > Bot Protection.

Widget Modes

• Invisible (recommended) — The challenge runs entirely in the background. No widget is shown to the user. Cloudflare's risk engine determines if additional verification is needed.
• Managed — Cloudflare decides whether to show an interactive checkbox widget based on its own risk signals.
• Off — Disable Turnstile. Use when self-hosting without Cloudflare access.

How It Works

1. The Turnstile widget loads on auth pages alongside the fingerprint SDK
2. On form submission, the widget generates a token using deferred execution (avoiding the 5-minute expiry problem)
3. The token is submitted with the form and verified server-side via Cloudflare's Siteverify API
4. A verified token provides a "Turnstile credit" that reduces the effective risk score by 0.15, potentially avoiding MFA challenges

Proof-of-Work

Wocha includes a built-in Proof-of-Work challenge system — a differentiating feature not offered by Auth0, Clerk, Kinde, or Stytch.

PoW challenges impose a computational cost on automated requests without any third-party dependency, making them ideal for:

• Self-hosted deployments without Cloudflare access
• Additional protection layered on top of Turnstile
• Scenarios where CAPTCHA is not appropriate

How It Works

1. The server generates a challenge with a random prefix and difficulty target (number of leading zero bits required in a SHA-256 hash)
2. The client solves the challenge in a Web Worker to avoid blocking the UI
3. The solution is submitted and verified server-side in O(1)

Difficulty Levels

Difficulty automatically escalates for repeat offenders via challenge velocity counters.

Per-Rule Challenge Actions

Each detection rule can be configured with an independent action:

• Block — Reject the request immediately
• Challenge — Present a CAPTCHA or MFA challenge
• Log — Record the event without enforcement (shadow mode per rule)

Configure per-rule actions in the Console under Security > Attack Protection > Detection Rules.

Challenge Velocity Limits

To prevent brute-force challenge solving, Wocha tracks challenge-related velocity:

Encrypted Signal Handling

When the fingerprint SDK operates with encryption enabled (recommended for production), the server cannot access individual bot signals directly. Wocha handles this by:

1. Using the client-computed bot_score and bot_reasons (which remain in plaintext) to synthesise boolean signal flags
2. Falling back to the raw bot_score when individual signal mapping is incomplete
3. Combining client-side heuristics with server-side Turnstile verification for defence in depth

This ensures bot detection remains effective regardless of the encryption configuration.

Integration with Adaptive MFA

Bot protection works seamlessly with the adaptive MFA system. When the challenge orchestrator selects mfa_step_up, it uses the same MFA infrastructure (TOTP, WebAuthn, SMS) with the same per-org policy enforcement.

The key difference: for bot-related risk signals, the system prefers CAPTCHA challenges over MFA, since a legitimate user with a slightly suspicious browser profile should not be forced through full MFA.