Clearance
A cf_clearance cookie proves to Cloudflare that the visitor is a verified human and has passed Cloudflare's client-side verifications.
The cookie contains two types of clearance that work together:
- Challenge clearance: Granted when a visitor solves a Challenge (for example, Interstitial Challenge Pages or Turnstile with pre-clearance enabled).
- Precursor clearance: Continuously updated based on session behavior.
The cookie is securely tied to the specific visitor and device it was issued to, preventing reuse across machines.
As an additional layer of security, Cloudflare recommends that customers add a rate limiting rule based on the cf_clearance cookie value. This helps ensure that a single, valid cookie cannot be abused by one machine to send an excessive volume of requests.
Challenge clearance is granted when a visitor successfully completes a Challenge.
Each challenge type sets a clearance level. A higher-level clearance bypasses all Challenges at or below that level. A lower-level clearance only bypasses challenges at the same level.
| Clearance level | Bypasses |
|---|---|
| Interactive (high) | Interactive, Managed, and Non-Interactive Challenges |
| Managed (medium) | Managed and Non-Interactive Challenges |
| Non-Interactive (low) | Non-Interactive Challenges only |
If a visitor passes an Interactive Challenge (highest security level), they can bypass all other Challenges for as long as the clearance remains valid.
If a visitor receives clearance at a lower level (Managed or Non-Interactive) and later encounters a higher-level challenge, they must solve the higher-level challenge again.
The original clearance is replaced if a higher-level challenge is later solved.
Challenge clearance remains valid for the duration configured by the customer (Challenge Passage), unless Precursor determines the session is suspicious.
Precursor clearance is continuously re-evaluated throughout a visitor’s session. Rather than being tied to a single challenge event, it operates as an ongoing, client-side process that periodically reassesses behavior at regular intervals. As new signals are observed, the clearance is updated dynamically to reflect the current level of trust in the session.
If Precursor determines that a session is suspicious:
- The visitor’s effective Challenge clearance may be reduced or invalidated.
- The visitor may be re-challenged, even if the cookie has not expired.
This creates a model where clearance is both time-bound (Interstitial) and behavior-bound (Precursor).
Pre-clearance in Turnstile allows websites to streamline user experiences by using cf_clearance cookies. The cf_clearance cookie enables visitors to bypass WAF Challenges on all subsequent requests on the zone, including API requests, based on the security clearance level set by the customer. This can be particularly useful for trusted visitors, enhancing usability while maintaining security.
By default, Turnstile issues a one-time use token to the visitor when they solve a challenge via the widget. You must validate the token by making a server-side call to the Siteverify API.
| Challenge type | Issued clearance |
|---|---|
| Challenge Page | cf_clearance cookie (default) |
| Turnstile widget | Token (default) cf_clearance cookie (optional addition) |
When you enable pre-clearance support on Turnstile, a cf_clearance cookie is issued to the visitor in addition to the default Turnstile token.
You can integrate Cloudflare Challenges by allowing Turnstile to issue a cf_clearance cookie as pre-clearance to your visitor. The pre-clearance level is set upon widget creation or widget modification using the Turnstile API's clearance_level. Possible values for the configuration are:
interactivemanagedjschallengeno_clearance
All widgets have pre-clearance mode set to false and the security clearance is set to no_clearance by default.
For Enterprise customers eligible to enable widgets without any pre-configured hostnames, Cloudflare recommends issuing pre-clearance cookies on widgets where at least one hostname is specified and is the same as the zone that you want to integrate with Turnstile.
Refer to the blog post ↗ for more details on how pre-clearance works with WAF.
Interactive (High) interactive
Allows a user with a clearance cookie to not be challenged by Non-Interactive Challenge, Managed Challenge, or Interactive Challenge Firewall Rules.
Managed (Medium) managed
Allows a user with a clearance cookie to not be challenged by Non-Interactive Challenge or Managed Challenge Firewall Rules.
Non-interactive (Low) jschallenge
Allows a user with a clearance cookie to not be challenged by Non-Interactive Challenge Firewall Rules.
Clearance cookies generated by the Turnstile widget will be valid for the time specified by the zone-level Challenge Passage value. To configure the Challenge Passage setting, refer to Challenge Passage.
To enable pre-clearance, you must ensure that the hostname of the Turnstile widget matches the zone with the WAF rules. During the Turnstile configuration setup in the Cloudflare dashboard, you have access to a list of registered zones. Select the appropriate hostname from this list.
The prerequisite is crucial for pre-clearance to function properly. If set up correctly, visitors who successfully solve Turnstile will receive a cookie with the security clearance level set by the customer. When encountering a WAF challenge on the same zone, they will bypass additional challenges for the configured clearance level and below.
For more details on managing hostnames, refer to the Hostname Management documentation.
-
In the Cloudflare dashboard, go to Turnstile.
Go to Turnstile -
Select Add widget.
-
Under Would you like to opt for pre-clearance for this site?, select Yes.
-
Choose a pre-clearance level.
-
Select Create.
-
In the Cloudflare dashboard, go to Turnstile.
Go to Turnstile -
Select an existing widget and open Settings.
-
Under Would you like to opt for pre-clearance for this site?, select Yes.
-
Choose a pre-clearance level.
-
Select Update.