Challenge suspicious sign-ups

Bots create fake accounts at scale to abuse free trials, send spam, or inflate sign-up numbers. Challenge suspicious sign-ups makes sign-ups that look automated, or that come through VPNs, Tor, or proxies, pass a challenge before the account is created. Sign-ups that don't match are never challenged.

What it challenges

A sign-up is challenged when either of these is true:

• Clerk's automated-traffic detection flags it as likely coming from a bot.
• It comes through a VPN, Tor, or a residential or datacenter proxy. iCloud Private Relay and corporate VPNs aren't treated as suspicious.

Challenge suspicious sign-ups applies to sign-ups only. It never challenges a sign-in.

A sign-up that carries a valid Testing Token isn't challenged, so end-to-end tests that use Testing Tokens keep running.

What happens when a sign-up is challenged

Clerk runs a Cloudflare Turnstile check in the user's browser. Most people pass it without doing anything, and some are asked to complete a CAPTCHA. When the check passes, the sign-up continues. If it doesn't pass, the account isn't created.

• Clerk's prebuilt <SignUp /> component shows the challenge inside the sign-up form.
• In a custom sign-up flow⁠, ClerkJS shows the challenge in a dialog over your page. See Handle sign-up challenges in your custom flow.

Each challenged sign-up appears as a protect.sign_up.challenged event in Application Logs.

Requirements

• ClerkJS 6.39.0 or later. Clerk's Core 3 SDKs load the latest ClerkJS 6 automatically. If your application uses an older version, the Dashboard shows Setup required. See Set up Protect.
• A Content Security Policy that allows the challenge. If your application sets a Content Security Policy, add the directives in Configure Clerk Content-Security-Policy headers.
• Support for challenges in custom sign-up flows. If you use a custom sign-up flow⁠, it must be able to display a challenge. See Handle sign-up challenges in your custom flow.

Before you enable Challenge suspicious sign-ups, the Clerk Dashboard checks your application for these requirements:

• Select Verify to have Clerk load your application's home URL and check its ClerkJS version and Content Security Policy.
• If the check can't reach your application, and you've confirmed the requirements yourself, select Bypass checks. This can't be undone.

Enable the protection

Challenge suspicious sign-ups is enabled by default for new applications. To enable or disable it:

1. In the Clerk Dashboard, under Protect, navigate to the Protections⁠ page.
2. In the Challenge suspicious sign-ups row, check the Status.
   • If Disabled, select Enable. In the dialog, toggle on Enable, then select Save.
   • If Enabled, the protection is already active. To disable it, select Manage, toggle off Enable, then select Save.
   • If Setup required, select Manage and complete the setup. See Requirements.

Native API and CAPTCHA

The Native API⁠ setting allows native applications and browser extensions to make requests to Clerk in environments that cannot always complete a browser-based CAPTCHA challenge. It enables a public request pathway through which CAPTCHA challenges are bypassed, even when legacy bot sign-up protection is on. Challenge suspicious sign-ups also doesn't challenge sign-ups from native applications while the Native API is enabled. While it's disabled, Clerk rejects every request from a native application with a native_api_disabled error, so a native sign-up fails instead of being challenged. Clerk's standard browser-based authentication flows continue to use CAPTCHA when a challenge is required.

Only enable the Native API when your native application or browser extension requires it. Because the pathway is public, it must not be treated as a secret or used as the only boundary protecting your application from automated traffic. Registering an application's bundle identifier or package name allows Clerk to validate callbacks for supported native authentication flows, but does not make the Native API pathway private.