How do I set up Cloudflare rate limiting to protect my login and API endpoints?

Most teams don’t think about rate limiting until a login or API endpoint is under brute-force attack or suddenly overloaded. Cloudflare’s rate limiting lets you put guardrails directly at the edge so abusive traffic never reaches your origin, while legitimate users and integrations continue to work.

Quick Answer: Cloudflare rate limiting lets you cap how many requests a client can make to your login and API endpoints in a given time window, then automatically block, challenge, or throttle abusive traffic at the edge. It’s one of the fastest ways to reduce credential stuffing, brute force, and noisy API abuse without changing your application code.

The Quick Overview

• What It Is: A Cloudflare security control that enforces request-per-time thresholds for specific URLs, methods, or traffic types, and applies actions (block, challenge, log) when a client exceeds those thresholds.
• Who It Is For: Security, DevOps, and application teams that need to protect login forms, password reset flows, and APIs (REST, GraphQL, JSON/HTTP) from brute-force attacks, credential stuffing, and abusive integrations.
• Core Problem Solved: Prevents a small number of clients from overwhelming sensitive endpoints, reduces attack surface for account takeover, and preserves origin resources by stopping attacks at Cloudflare’s edge.

How It Works

At a high level, Cloudflare sits in front of your sites and APIs as a connectivity cloud, routing all HTTP(S) traffic through its global edge network. Rate limiting policies are evaluated at that edge—within ~50 ms of most Internet users—so abusive clients are blocked before they hit your infrastructure.

When you define a rate limiting rule (for example, “no more than 10 POST requests to /login per IP per minute”), Cloudflare:

1. Matches requests against the rule’s filters (URL path, method, headers, etc.).
2. Counts matching requests per “key” (commonly IP address, but you can shape by other attributes in more advanced setups).
3. Enforces the configured action (block, challenge, log-only) when the threshold is exceeded, optionally for a defined timeout period.

Because this all happens at the edge, your origin server offloads the heavy lifting of rejecting abusive traffic and can focus on legitimate authentication and API work.

Step-by-step flow for login and API protection

1. Edge inspection and matching:
   Incoming requests to your login and API endpoints are routed through Cloudflare. Rules look at request properties—HTTP method, URL, query string, and sometimes header/body characteristics (for API patterns)—to determine if they should count toward a specific rate limit.

2. Counting and threshold evaluation:
   For matching requests, Cloudflare increments a counter per client key (often IP). If the request rate stays below the threshold, traffic passes through normally. If the threshold is exceeded within your configured period, Cloudflare immediately starts applying your chosen mitigation.

3. Mitigation and logging:
   Once triggered, Cloudflare can block subsequent requests, challenge them (e.g., with a managed challenge), or log them for analysis only. Events are visible in Cloudflare’s dashboard and logs, so you can tune thresholds and actions with real data.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Per-endpoint rate rules	Apply different limits to /login, /password-reset, /api/*, and other sensitive paths.	Tailor protection to how each endpoint behaves (logins vs. APIs vs. public pages).
Edge-based enforcement	Evaluates request rate and applies actions at Cloudflare’s global edge.	Reduces load on your origin and stops brute-force traffic before it reaches your network.
Flexible actions & observability	Choose to block, challenge, or log only, with detailed event logging.	Tune and iterate safely, starting in monitor-only mode before enforcing strict blocks.

Ideal Use Cases

• Best for login & authentication flows: Because it sharply limits brute-force and credential-stuffing attempts against /login, /auth, and /password-reset endpoints without impacting legitimate users making a small number of attempts.
• Best for public APIs and webhooks: Because it caps abusive integrations or misconfigured clients hitting /api/* or /v1/graphql, keeping noisy traffic from degrading performance for legitimate consumers.

Practical Setup: Recommended Patterns

Below is a concrete approach I’ve used in real VPN-to-Zero-Trust migrations, adapted to Cloudflare’s rate limiting.

1. Identify critical endpoints

Start with the highest-impact targets:

• Login: /login, /signin, /auth, /oauth/token, /api/auth/*
• Account recovery: /password-reset, /forgot-password
• APIs: /api/*, /v1/*, /graphql
• Administrative: /admin/*, /dashboard/* (especially if exposed to the Internet)

Document for each:

• Typical user behavior (e.g., most humans don’t submit a login form more than a handful of times per minute).
• Typical API consumer behavior (e.g., a mobile app might send tens of requests/minute; a batch integration might send hundreds).

This behavior baseline is what you’ll translate into rate limits.

2. Start in log/monitor mode

When you first deploy rules, the safest pattern is:

• Create rate limits with realistic thresholds.
• Set the action to “log” or “simulate” (depending on your plan and feature set).
• Let them run for a few days and review traffic patterns and near-misses.

This reduces the risk of blocking legitimate bursts (like a peak login hour or a scheduled integration job).

3. Design separate rules for logins vs APIs

Treat humans and machines differently.

Login endpoints (human traffic)

Typical pattern: low frequency, small bursts, IPs mostly residential or mobile.

Example rule ideas:

• Rule: Protect /login POSTs

  • Filter: http.request.method == "POST" and http.request.uri.path eq "/login"
  • Threshold: 10 requests per IP per 60 seconds
  • Action:
    • Phase 1 (monitoring): Log-only
    • Phase 2 (enforcement): Block or challenge for 10–15 minutes after threshold is exceeded

• Rule: Protect OAuth token endpoint

  • Filter: http.request.method == "POST" and http.request.uri.path contains "/oauth/token"
  • Threshold: 30 requests per IP per 60 seconds
  • Action: Similar: start with log-only, then block.

These limits dramatically slow down brute-force and credential stuffing while leaving regular users unaffected.

API endpoints (machine traffic)

Typical pattern: higher frequency, often from data centers or cloud providers, sometimes bursty but predictable by client.

Consider separating:

• Public client API (mobile/SPA): moderate, steady rate.
• Partner/enterprise API: higher sustained rate, often from known IPs.
• Internal API exposed to the Internet: should have tight controls and maybe IP allowlists via Cloudflare Access or API Shield.

Example rule ideas:

• Rule: Protect generic REST API

  • Filter: http.request.uri.path starts_with "/api/"
  • Threshold: 1000 requests per IP per 60 seconds (adjust based on traffic)
  • Action: Log-only first; then block or challenge.

• Rule: Protect GraphQL endpoint

  • Filter: http.request.uri.path contains "/graphql"
  • Threshold: 500 requests per IP per 60 seconds
  • Action: Start in observe, then block when confident.

For high-volume trusted partners, you can:

• Exempt specific IP ranges or API tokens (via custom filter conditions).
• Use separate, higher-threshold rules targeting those IPs.

4. Tune thresholds based on real traffic

Once you’ve run with log-only actions:

• Pull Cloudflare logs or dashboard analytics for your rate limit rules.
• Look at IPs that would have triggered a block:
  • Are they obviously malicious (suspicious ASNs, impossible login patterns)?
  • Do they align with known integrations or legitimate bulk activity?

Adjust thresholds upward if you’re catching legitimate patterns; downward if attacks are still slipping through without being rate-limited.

5. Move to enforcement and layer with other Cloudflare controls

After tuning:

• Switch from log-only to block or challenge actions for sensitive logins.
• For APIs, consider:
  • Block for clearly abusive IPs.
  • Challenge for suspicious-but-uncertain patterns, so well-behaved clients can still pass.

Combine rate limiting with:

• Cloudflare WAF & bot protection (Application Services):
  • Use WAF managed rules and bot detection to stop known bad signatures and automated tools before rate limits even come into play.
• Zero Trust access (Cloudflare One):
  • For admin panels or internal APIs, put them behind Cloudflare Access so every request is gated by identity and context, not just IP or rate.
• API Shield (if applicable):
  • Enforce mTLS, schema validation, and token-based access for APIs, with rate limits as a secondary control.

Limitations & Considerations

• One-dimensional keys (IP-based):
  Basic rate limiting is often keyed by IP. This can be less effective behind large NATs (many users sharing one IP) or if attackers rotate IPs. Workaround: Use Cloudflare’s more advanced HTTP filtering and pair rate limits with WAF, bot management, and identity-based controls where possible.

• Legitimate high-volume clients:
  Bulk integrations, trusted partners, or internal tools may exceed generic thresholds. Workaround: Create specific allow or higher-threshold rules for known IP ranges, or separate them onto dedicated subdomains/paths with tailored policies.

Pricing & Plans

Rate limiting capabilities vary by Cloudflare plan and product tier, but the pattern is:

• Available as part of Cloudflare’s Application Services when you proxy your website or API through the connectivity cloud.
• Higher plans typically offer:
  • More rules.
  • Finer-grained controls and analytics.
  • Better integration with WAF, bot management, and advanced logging.

Contact Cloudflare sales or review the current plan comparison for the latest feature-level details.

• Standard / Business-style plans: Best for teams needing straightforward rate limits on a handful of login and API endpoints with simple per-IP thresholds.
• Enterprise: Best for organizations needing granular rule logic, higher rule counts, tight integration with Zero Trust and API Shield, and support for complex login and API architectures.

Frequently Asked Questions

How strict should I set Cloudflare rate limiting for my login endpoint?

Short Answer: Start with a human-friendly baseline like 10 POST requests per IP per minute to /login, monitor, then tighten or relax based on observed traffic.

Details:
Most legitimate users will:

• Attempt login 1–3 times in quick succession if they mistype a password.
• Rarely submit more than 5–6 attempts in under a minute.

So a starting point of 10 requests per IP per 60 seconds is generous enough to avoid false positives, but harsh enough to slow down brute-force scripts. Use Cloudflare logs to validate:

• If no legitimate traffic approaches that threshold, consider tightening (e.g., 6–8/min).
• If legitimate users or SSO flows hit the limit (e.g., during peak traffic), either raise it or carve out exceptions for specific sources (like your SSO IdP callback endpoints).

Will Cloudflare rate limiting break my public API or mobile app?

Short Answer: It won’t if you base thresholds on actual traffic and test in log-only mode first.

Details:
API and mobile traffic patterns differ from login traffic: they can burst, and they can come from shared IPs (corporate proxies, NATed mobile networks). To avoid breaking them:

1. Run rate limit rules in log/monitor mode for a few days.
2. Review:
   • Top IPs by request volume.
   • Which endpoints they hit.
   • Whether they match legitimate clients or attackers.
3. Adjust thresholds to sit safely above normal peaks, but below abusive patterns.
4. When in doubt, prefer a challenge action for APIs over outright block, and layer in WAF and API Shield protections for deeper control.

You can also segment your API endpoints by path or subdomain so high-volume, trusted clients have their own tailored rate limits.

Summary

Protecting login and API endpoints with Cloudflare rate limiting is one of the fastest ways to reduce brute-force attacks, credential stuffing, and abusive integrations—without rewriting your applications. By routing traffic through the connectivity cloud and enforcing thresholds at the edge, you:

• Keep attack traffic off your origin.
• Make login and API abuse materially more expensive for attackers.
• Gain clear visibility into who’s pushing your endpoints hardest.

When paired with Cloudflare WAF, bot protection, and Zero Trust access, rate limiting helps you connect, protect, and build everywhere on a defensible architecture where every request is evaluated and logged at the edge.

Next Step

Get Started