Stop Abusive Account Signups & Credential Stuffing

Your registration or login forms are hit by thousands of automated bot submissions daily, cluttering your user database and draining transactional email allowances.

Why standard application-level defenses fall short

Modern attack campaigns no longer originate from single static IP addresses. Automated botnets leverage rotating residential proxy pools and spoof legitimate browser footprints to evade simplistic controls:

Ineffective static IP banning: Attackers distribute attempts across thousands of unique IP addresses, rendering single-IP blocklists obsolete within minutes.
Conversion friction from legacy visual CAPTCHAs: Forcing real users to click image puzzles damages signup rates while modern AI models and solver farms easily bypass them.
Origin server resource exhaustion: Computing cryptographic password hashes (bcrypt, argon2) or firing verification emails on every bot attempt overwhelms server CPU and mail queues.
Carding and payment gateway abuse: Cybercriminals test stolen credit card numbers against public checkout endpoints in rapid bursts, risking merchant account suspension.

The cost goes far beyond a polluted database. Every fake account triggers a welcome email to a mailbox provider, and bounce patterns like these teach spam filters to distrust your sending domain. Once credential stuffing succeeds against reused passwords, account takeover complaints, support tickets and chargebacks follow. The only defense that scales is one applied at the edge, before a single bot request ever consumes application resources.

A multi-layered edge defense strategy

To intercept malicious bots before they ever reach your backend infrastructure:

Targeted Rate Limiting on POST methods and sensitive endpoints: Enforce strict request thresholds per IP or session footprint on /api/login, /signup, and /checkout.
Seamless Cloudflare Turnstile integration: Replace intrusive CAPTCHAs with invisible Cloudflare Turnstile verification validated server-side.
Datacenter ASN filtering: Challenge or block authentication requests originating from cloud hosting providers (AWS, DigitalOcean, Hetzner, OVH) that never represent organic consumer browsing.
Browser navigation header inspection: Validate modern security headers (Sec-Fetch-Site, Sec-Fetch-Mode, Referer) to filter automated cURL scripts and primitive headless scrapers.

Layering matters because no single rule catches every botnet. Residential proxies defeat ASN filtering, distributed timing defeats naive rate limiting, and forged headers defeat signature matching. Each layer removes one class of attacker, and what remains is small enough to be handled by a challenge. If the rules you have already deployed are also catching legitimate customers, work through our guide on security rule false positives on signups and checkout before adding more layers.

Fixing abusive signups on Cloudflare, step by step

Before changing anything, quantify. Then roll out enforcement progressively, verifying at each stage that real users still convert. Here is the sequence that works on a standard zone:

Measure the attack. In the Cloudflare dashboard, open Security > Events and filter on the path of the abused form, for example http.request.uri.path contains "/signup". Note the request volume per hour, the top source ASNs, the country distribution, and whether the requests carry realistic browser headers. This is your baseline; without it you cannot demonstrate improvement later.
Protect the login endpoint with a rate limiting rule. Under Security > WAF > Rate limiting rules, create a rule that counts matching requests over a short window. A realistic starting configuration for credential stuffing:

Expression:
  (http.request.method == "POST" and http.request.uri.path contains "/login")
With the same characteristic: IP address
Count: 5 requests over 1 minute
Action: Managed Challenge, mitigation timeout 10 minutes

Duplicate the logic for /signup and, if you run e-commerce, for /checkout to blunt carding bursts. Tune the threshold against your baseline: it should sit far below observed attacker volume and comfortably above genuine user behavior, including employees behind a shared corporate NAT address.

Challenge suspicious sources with a custom security rule. Under Security > WAF > Custom rules, combine Cloudflare's built-in threat intelligence with the request method:

Expression:
  cf.threat_score gt 30 and http.request.method == "POST"
Action: Managed Challenge

The cf.threat_score field aggregates Cloudflare intelligence about the source IP: spam history, proxy network participation, malware activity. Never block outright on this score alone; challenge instead, so that the rare legitimate visitor behind a flagged address can still pass.

Exempt verified good bots. If search crawlers or monitoring services legitimately POST to your endpoints (ping submissions, uptime checks), place a Skip rule above the challenge rules with the expression cf.client.bot. This Cloudflare-managed field only matches crawlers validated by reverse DNS, never spoofed user agents.
Add Turnstile to the form itself. Create a widget in the Turnstile section of the dashboard, embed it in your signup and login forms, and verify the token server-side before processing the submission. For humans it runs invisibly; for scripts that cannot execute JavaScript, the form simply never validates.
Watch, then iterate. Return to Security > Events after 24 to 48 hours: the bot wave should now hit Challenge or Block actions, while your application analytics confirm that legitimate signups still complete. Adjust thresholds one step at a time, never several at once, so each effect is attributable.

Common mistakes

These are the errors we see most often when reviewing zones that are still being abused despite Cloudflare being in front of the site:

Filtering on user agent strings alone. An expression like http.user_agent contains "bot" stops nothing serious: the string is trivially spoofed by any HTTP client, and the same broad matching also catches the http.user_agent contains "Googlebot" traffic you actually want to keep. Base your rules on fields the client cannot forge, such as cf.client.bot, cf.threat_score and ASN data.
Rate limiting every endpoint at once. A single aggressive quota applied to the whole domain punishes normal browsing and squeezes anyone behind shared egress IPs, such as office networks and universities. Rate limit only sensitive methods (POST) and the few paths that are actually abused.
Leaving "I'm Under Attack" mode enabled permanently. The JavaScript interstitial breaks every non-browser client: mobile applications, server-to-server APIs, cron jobs and payment provider callbacks. It is an emergency lever for an active attack, not a standing configuration.
Blocking by country or ASN without exceptions. Shutting out entire regions can stop the current wave, but it also cuts real customers and, depending on how the rule is written, search engine crawlers. If you must geofence, build the verified-bot exception first; our guide on accidental Googlebot blocking and SEO drops shows the exact expressions.
Changing rules without a baseline. If you cannot compare before and after, you cannot tell whether the attack stopped or simply moved to another endpoint. Capture Security > Events statistics before the first change, and re-measure after each one.

Frequently asked questions

Will rate limiting block my real customers?

Rarely, when the rule is scoped correctly. A limit applied to POST requests on a single login path almost never catches a human, who may attempt two or three logins in a minute at worst. Problems appear when the same quota covers the entire domain or counts GET requests. Using a Managed Challenge action instead of a hard Block also lets the occasional over-threshold human through.

What is the difference between Bot Fight Mode and custom security rules?

Bot Fight Mode is a one-click product that scores and challenges suspected bots, with no configuration. It stops simple attacks but cannot be tuned, which is why it sometimes blocks legitimate traffic, as detailed in our guide on Bot Fight Mode false positives. Custom security and rate limiting rules are the opposite: more work to write, but scoped exactly to your endpoints and adjustable over time.

Should I block disposable email domains at the edge?

No. Cloudflare sees the HTTP request, not the content of the submitted form fields, so a security rule cannot reliably test the email address being registered. Filter disposable domains inside your application logic, and reserve the edge for volumetric and fingerprint defenses: rate limiting, ASN classification and Turnstile.

How fast do new rules take effect?

security and rate limiting rules propagate globally within seconds of deployment, which is precisely why care is needed: a bad expression goes worldwide just as fast. Where the product allows it, deploy a new rule in Log action first, review what it would have matched for a few hours, then switch it to challenge or block with confidence.

Stopping Waves of Abusive Signups and Credential Stuffing Attacks