Stop account takeover attacks (Free, Pro, và Business) Stop account takeover attacks (Free, Pro, and Business)

Always Use HTTPS redirects all visitor requests from http to https for all subdomains and hosts.

• Dashboard
• API

To enable Always Use HTTPS in the dashboard:

1. In the Cloudflare dashboard, go to the SSL/TLS Overview page.

Go to Overview

1. Make sure that your SSL/TLS encryption mode is not set to Off. When you set your encryption mode to Off, the Always Use HTTPS option will not be visible in your Cloudflare dashboard.
2. Go to the Edge Certificates ↗ page.
3. Turn on Always Use HTTPS.

To enable or disable Always Use HTTPS with the API:

1. Make sure that your SSL/TLS encryption mode is not set to Off.
2. Send a PATCH request with alwaysusehttps as the setting name in the URI path, and the value parameter set to your desired setting ("on" or "off").

Cloudflare recommends not performing redirects at your origin web server, as this can cause redirect loop errors.

Optional: HTTP Strict Transport Security (HSTS)

For additional transport hardening, consider enabling HTTP Strict Transport Security (HSTS). HSTS tells browsers to only connect over HTTPS, preventing downgrade attacks on the initial request. HSTS is irreversible for the configured Max Age duration. If you later disable HTTPS, your site becomes inaccessible until the Max Age expires. Review the HSTS requirements before turning it on.

Bot Fight Mode challenges requests that match known bot patterns. It applies to all traffic on your domain and cannot be customized with exceptions or path-specific rules.

• New dashboard
• Old dashboard

1. In the Cloudflare dashboard, go to the Security Settings page.

Go to Settings

1. Filter by Bot traffic.
2. Go to Bot fight mode.
3. Turn Bot fight mode on.

1. Log in to the Cloudflare dashboard ↗, and select your account and domain.
2. Go to Security \> Bots.
3. For Bot Fight Mode, select On.

Bot Fight Mode cannot be skipped by custom rules because it does not run inside the Ruleset Engine. If you need to exempt specific traffic (monitoring tools, partner APIs), upgrade to Super Bot Fight Mode on the Pro plan.

Super Bot Fight Mode identifies traffic matching patterns of known bots, can challenge or block bots, and offers protection for static resources. You configure a separate action for each bot grouping: Definitely automated, Likely automated, and Verified bots. You can also configure exceptions using Application Security custom rules with the Skip action.

If you are upgrading from Bot Fight Mode to Super Bot Fight Mode, you must disable Bot Fight Mode in your Bot settings.

• Old dashboard: Security \> Bots, and select Configure Bot Fight Mode.
• New dashboard: Security \> Settings. Filter by Bot traffic and turn Bot fight mode off.

• New dashboard
• Old dashboard

1. In the Cloudflare dashboard, go to the Security Settings page.

Go to Settings

1. Filter by Bot traffic.
2. Go to Super Bot fight mode.
3. Turn Super Bot fight mode on.
4. Choose how your domain should respond to various types of traffic by selecting the associated edit icon:

For more details on verified bots, refer to Verified Bots. For more details on supported file types, refer to Static resource protection. For more details on invisible code injection, refer to JavaScript detections. For more details on WordPress optimization, refer to Super Bot Fight Mode for WordPress.

1. Log in to the Cloudflare dashboard ↗, and select your account and domain.
2. Go to Security \> Bots.
3. Select Configure Super Bot Fight Mode.
4. Choose how your domain should respond to various types of traffic:

For more details on verified bots, refer to Verified Bots. For more details on supported file types, refer to Static resource protection. For more details on invisible code injection, refer to JavaScript detections. For more details on WordPress optimization, refer to Super Bot Fight Mode for WordPress.

For login protection, the following are recommended starting values. Adjust based on your traffic patterns.

• Definitely automated: Managed Challenge. After reviewing Security Events to confirm the setting does not affect legitimate traffic, switch to Block.
• Likely automated: Managed Challenge.
• Verified bots: Allow.

Warning

If your organization also uses Cloudflare Tunnel, keep Definitely Automated set to Allow. Otherwise, tunnels might fail with a websocket: bad handshake error.

Custom rules are executed before Super Bot Fight Mode. To create exceptions for specific paths or traffic, create a custom rule with the Skip action. The Skip action allows the request to bypass the Super Bot Fight Mode phase without terminating the request, enabling it to continue through the rest of the security stack.

Implementing Turnstile involves three steps: create a widget, add the client-side snippet to your login form, and validate the token on your server. Turnstile supports multiple rendering methods including explicit and implicit rendering. You can also inject Turnstile into HTML using a Cloudflare Worker if you do not control the login form source code.

Turnstile is configured at the account level.

1. In the Cloudflare dashboard, go to the Turnstile page.

Go to Turnstile

1. Select Add widget.
2. Fill out the required information:

Widget name: A descriptive name for your widget. Hostname management: Domains where the widget will be used. * Widget mode: Choose from Managed, Non-Interactive, or Invisible.

1. (Optional) Configure Pre-clearance support for single-page applications.
2. Select Create to save your widget.
3. Copy your sitekey and secret key, and store the secret key securely.

You need both the sitekey and secret key in the following steps.

Add the Turnstile script and widget container to your login form. Replace <YOUR-SITE-KEY> with the sitekey from the previous step.

<form id="login-form">

  <input type="text" id="username" placeholder="Username" required />

  <input type="password" id="password" placeholder="Password" autocomplete="off" required />

  <div class="cf-turnstile" data-sitekey="<YOUR-SITE-KEY>"></div>

  <button type="submit">Log in</button>

</form>


<script

  src="https://challenges.cloudflare.com/turnstile/v0/api.js"

  async

  defer

></script>

The widget renders inside the div and produces a token when the visitor passes the challenge. When the form is submitted, a cf-turnstile-response token is included in the form data.

Before processing the form submission, send the token to the Turnstile siteverify endpoint to confirm the visitor passed the challenge.

server.js

const SECRET_KEY = "<YOUR-SECRET-KEY>";


async function validateTurnstile(token, remoteip) {

  try {

    const response = await fetch(

      "https://challenges.cloudflare.com/turnstile/v0/siteverify",

      {

        method: "POST",

        headers: {

          "Content-Type": "application/json",

        },

        body: JSON.stringify({

          secret: SECRET_KEY,

          response: token,

          remoteip: remoteip,

        }),

      },

    );


    const result = await response.json();

    return result;

  } catch (error) {

    console.error("Turnstile validation error:", error);

    return { success: false, "error-codes": ["internal-error"] };

  }

}

Replace "<YOUR-SECRET-KEY>" with your Turnstile secret key. The endpoint returns a JSON object with a success field. Only process the form submission if success is true.

For additional fraud detection, Turnstile supports Ephemeral IDs that provide a unique, temporary identifier for each visitor session without storing personal data.

For the complete response format, error codes, and examples in other languages, refer to Validate the token.

Turnstile provides test site keys that return predictable results without contacting the Siteverify API.

• Always passes: Use site key 1x00000000000000000000AA and secret key 1x0000000000000000000000000000000AA to simulate a successful challenge.
• Always blocks: Use site key 2x00000000000000000000AB and secret key 2x0000000000000000000000000000000AA to simulate a failed challenge.
• Forces interactive challenge: Use site key 3x00000000000000000000FF to test the interactive challenge flow.

For the full list of test keys and expected behaviors, refer to Test your Turnstile implementation.

The following example creates a rate limiting rule that issues a Managed Challenge after more than five POST requests to your login path from the same IP within one minute. Start with Managed Challenge rather than Block. Managed Challenge allows legitimate users who trigger the limit to pass by completing a challenge, while blocking automated traffic that cannot solve it. After monitoring Security Events to confirm the rule is not producing false positives, switch to Block. Adjust the path (/login), threshold, and period for your site.

Warning

Managed Challenge and other challenge types require an HTML response to render. They do not work for non-HTML responses such as AJAX/XHR requests, which are common on login endpoints that use single-page applications (SPAs) or API-based authentication. If your login flow uses AJAX, consider using Turnstile Pre-Clearance instead.

1. In the Cloudflare dashboard, go to the Security rules page.

Go to Security rules

1. Select Create rule and choose Rate limiting rules.
2. Enter a name for the rule (for example, "Rate limit login endpoint").
3. Under When incoming requests match, select Edit expression and enter: http.host eq "example.com" and http.request.uri.path eq "/login" and http.request.method eq "POST"

Replace \example.com\ with your domain and \/login\ with your login endpoint path.

1. Under With the same characteristics, verify that IP is selected. On Free plans, this is preset to IP.
2. Under When rate exceeds, enter 5 for Requests and select a value for Period. On Free plans, select 10 seconds. Pro and above plans offer additional periods. For available values by plan, refer to Rate limiting parameters.
3. Under Then take action, select an action from the Choose action dropdown. On Free plans, select Block. On Pro and above, Managed Challenge is recommended because it allows legitimate users who trigger the limit to pass by completing a challenge.
4. Under For duration, select a duration for the action. On Free plans, select 10 seconds. Pro and above plans offer longer durations. This is how long the action applies after the rate limit is triggered.
5. Select Deploy.

(Optional) To count only failed login attempts instead of all matching requests, Business plan and above users can add a separate counting expression under Increment counter when:

http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}

This counts requests based on the response status code. Successful logins (200) do not increment the counter.

Advanced Rate Limiting (Enterprise)

Enterprise customers with Advanced Rate Limiting can rate limit by characteristics beyond IP address, which is useful when attackers distribute attempts across many IP addresses. For available characteristics and plan availability, refer to Rate limiting parameters.

For sites that experience sustained credential stuffing campaigns, consider deploying multiple rate limiting rules with increasing severity. The Rate limiting best practices page describes an escalating penalty pattern that uses three rules: a short-window rule for quick bursts, a medium-window rule for slower distributed attacks, and a long-window rule that blocks persistent attackers from the entire domain. The counting expressions use response status codes, so successful logins do not count against the limit. Refer to the best practices page for the recommended thresholds and expression syntax.

These example rules require a Business plan or above because they use counting expressions that reference HTTP response codes.

Leaked credentials detection scans incoming login requests for usernames and passwords that appear in known data breach databases. Cloudflare hashes credentials before comparison and does not store plaintext passwords. When a match is found, the detection populates fields you can use in custom rules and rate limiting rules.

The cf.waf.credentialcheck.passwordleaked field is available on all plans.

The cf.waf.credentialcheck.usernameandpasswordleaked field requires a Pro plan or above.

On Free plans, the leaked credentials detection is enabled by default, and no action is required. On paid plans, you can turn on the detection in the Cloudflare dashboard, via API, or using Terraform.

• New dashboard
• Old dashboard
• API
• Terraform

1. In the Cloudflare dashboard, go to the Security Settings page.

Go to Settings

1. (Optional) Filter by Detection tools.
2. Turn on Leaked credential detection.

1. Log in to the Cloudflare dashboard ↗, and select your account and domain.
2. Go to Security \> Settings.
3. Under Incoming traffic detections, turn on Leaked credentials.

Use a POST request similar to the following:

Required API token permissions

At least one of the following token permissionsis required:

• Zone WAF Write
• Account WAF Write

Set Leaked Credential Checks Status

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/leaked-credential-checks" \

  --request POST \

  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \

  --json '{

    "enabled": true

  }'

Use the cloudflareleakedcredential_check resource to enable leaked credentials detection for a zone. For example:

resource "cloudflare_leaked_credential_check" "zone_lcc_example" {

  zone_id = var.cloudflare_zone_id

  enabled = true

}

After turning on the detection, your origin server can receive leaked credential status via the Exposed-Credential-Check request header. To forward this header, turn on the Add leaked credentials checks header managed transform. Your origin can then trigger a password reset for affected users.

Enterprise: Custom detection locations

If your application uses non-standard credential field names, Enterprise customers can configure custom detection locations to tell Cloudflare where to find usernames and passwords in HTTP requests.

Before deploying rules that challenge or block login traffic, create a skip rule that exempts known legitimate automated traffic. This prevents your monitoring tools, health checks, and partner integrations from being blocked by the rules that follow.

1. In the Cloudflare dashboard, go to the Security rules page.

Go to Security rules

1. Select Create rule and choose Custom rules.
2. Enter a name for the rule (for example, "Skip login rules for known clients").
3. Select Edit expression and enter an expression that matches your legitimate automated traffic. For example, to skip verified bots and a specific monitoring service IP:

(cf.client.bot) or (ip.src eq 198.51.100.1)

Replace 198.51.100.1 with the IP address of your monitoring service. Add additional conditions for other known clients.

1. Under Then take action, select Skip. Under WAF components to skip, select the components that apply to your login protection rules (for example, All remaining custom rules and All rate limiting rules).
2. Select Deploy.
3. Under Place at, place the rule above your blocking and challenge rules. Custom rules execute in order, so the skip rule must come first.

For more information about the Skip action and available skip options, refer to Skip action.

Credential stuffing tools often send requests without standard browser headers or with known-bad User-Agent patterns. Create a custom rule that issues a Managed Challenge for POST requests to your login path where the User-Agent is empty. This targets direct POST requests from tools like curl, python-requests, or undici that do not set a User-Agent header.

The Application Security Managed Ruleset includes rules for empty user-agents, but these are disabled by default and apply broadly. The custom rule below targets your login path specifically.

1. In the Cloudflare dashboard, go to the Security rules page.

Go to Security rules

1. Select Create rule and choose Custom rules.
2. Enter a name for the rule (for example, "Challenge empty UA on login").
3. Select Edit expression and enter:

(http.request.uri.path eq "/login" and http.request.method eq "POST" and len(http.user_agent) eq 0)

Replace /login with your login endpoint path.

1. Under Then take action, select Managed Challenge.
2. Select Deploy.

Combine rate limiting with leaked credentials detection to throttle login attempts that use known-compromised passwords. This rule issues a Managed Challenge when the same IP sends more than three requests with leaked passwords within one minute.

1. On the Security rules page, select Create rule and choose Rate limiting rules.

Go to Security rules

1. Enter a name for the rule (for example, "Rate limit leaked credentials").
2. Under When incoming requests match, enter the following expression:

http.request.uri.path eq "/login" and http.request.method eq "POST" and cf.waf.credential_check.password_leaked

Replace /login with your login endpoint path.

1. Under With the same characteristics, verify that IP is selected. On Free plans, this is preset to IP.
2. Under When rate exceeds, enter 3 for Requests and select a value for Period. On Free plans, select 10 seconds.
3. Under Then take action, select an action. On Free plans, select Block. On Pro and above, Managed Challenge is recommended.
4. Under For duration, select a duration for the action. On Free plans, select 10 seconds.
5. Select Deploy.

Enterprise: Bot Management

Enterprise customers with Bot Management get additional tools for login protection:

• Custom rules with bot scores: combine cf.bot_management.score with login path matching for precise control. Refer to Custom rules for bot protection.
• Account takeover detections: monitor suspicious login volume and failure rates using detection IDs in custom rules and rate limiting rules. Refer to Account takeover detections.
• Account Abuse Protection (Early Access): detect account fraud patterns beyond credential stuffing. Refer to Account Abuse Protection.

Security Events shows requests that Cloudflare security products acted on or flagged, including blocks, challenges, and skips.

1. In the Cloudflare dashboard, go to the Analytics page.

Go to Analytics

1. Select the Events tab.

Review the Sampled logs to inspect individual requests. Each log entry shows the action taken, the rule that triggered, the source IP, user agent, URI path, and country. Use the Add filter button to narrow results by action, source IP, ASN, or other fields.

Look for false positives — legitimate traffic that your rules incorrectly challenged or blocked. Common signs include:

• Requests from known monitoring services or payment processors appearing in blocked events
• High volumes of challenged requests from countries where you have real users
• Rate limiting rules triggering on legitimate users during peak traffic

If you see legitimate users being affected, adjust your rate limiting thresholds or add skip rules for specific IP ranges.

Set up a Security Events Alert notification to receive alerts when security event volume spikes, giving you early warning of a new attack campaign. This notification is in the WAF category of the Notifications page. For setup instructions, refer to Create a notification. Enterprise customers can use Advanced Security Events Alert for more granular filtering.

Bot traffic analytics show bot score distribution on your login endpoint over time. A sudden spike in low-score traffic (scores 1-29) on your login path is an early signal of a credential stuffing campaign.

Cloudflare classifies bot traffic into categories based on bot scores and verification status:

• Verified bots: Crawlers and services that Cloudflare has confirmed as legitimate, such as Googlebot, Bingbot, and uptime monitors. Cloudflare maintains a verified bot list with strict requirements.
• Automated (score 1): Cloudflare is quite certain the request is automated.
• Likely automated (scores 2-29): Probably a bot. This category and Automated are the primary targets for security rules, including scrapers, credential stuffing tools, and spam submitters.
• Likely human (scores 30-99): These requests appear to come from real users. Do not challenge or block this traffic.

1. In the Cloudflare dashboard, go to Security \> Analytics \> Bot analysis.
2. Review the traffic distribution across the bot score groupings above.

If you see sustained automated traffic reaching your login endpoint despite the rules deployed in this guide, review the Security features interoperability page to verify your rules are executing in the expected order, and consider adjusting thresholds.