Identify the exact login hostname, path and method, plus normal request rates. Separate human login from API authentication and review any application-side lockout or multi-factor controls already in place.

1. Open Security rules and choose Create rule > Rate limiting rules.
2. Match the specific endpoint and appropriate method instead of the entire website. Review whether cached assets are included in counting.
3. Choose available counting characteristics, a measured request threshold, evaluation period and mitigation duration. Do not copy a threshold without comparing it with legitimate usage.
4. Select an action suitable for the client type. A browser challenge may be inappropriate for an API or payment callback.
5. Deploy, test normal login and inspect triggered events. Adjust using evidence while keeping a clear rollback path for accidental lockouts.

For a fictional application whose browser login submits to https://accounts.example.com/login, the match below narrows the rule to that hostname, path and method. Use it only if those are the actual route and supported rule fields for your service.

http.host eq "accounts.example.com" and
http.request.uri.path eq "/login" and
http.request.method eq "POST"

Measure legitimate submissions, including users sharing an office connection, before choosing the available counting period and threshold. A page load, failed password and successful login are different application events; this expression identifies HTTP submissions, not their outcome. Select an action compatible with the client.

Expected result: ordinary login still works, excessive matching submissions produce the intended event, and the home page, password-reset path and separate APIs remain outside this particular rule. Review the rest of the authentication flow independently instead of assuming this one rule protects every endpoint.

Excessive requests should be mitigated without preventing ordinary customers from signing in. Evaluate users behind shared NAT or corporate networks when IP-based counting is involved.

Available fields, periods and actions vary by plan. Rate limits do not replace strong passwords, application authentication or multi-factor protection. If bots simply move to another endpoint, review the whole login flow rather than globally blocking normal traffic.

No. A request counter observes HTTP traffic according to its configuration. It does not automatically understand application success or failure unless supported response-based conditions are deliberately configured.

• Creating a narrowly scoped Cloudflare WAF custom rule
• Reading Cloudflare security events for an incident
• Adding Cloudflare Turnstile with mandatory server-side verification
• Adjusting Cloudflare Challenge Passage

• Cloudflare: Create Zone Dashboard
• Cloudflare: Best Practices