How to Mitigate HTTP Flood and Layer 7 Attacks

Short answer: A layer 7 flood is made of requests that look identical to legitimate ones, so buying capacity never solves it — classification does. Identify it with four signals: URI concentration, broken request chains (no assets, no referrer progression), fingerprints such as JA4 and session reuse, and per-endpoint tail latency. Then mitigate in this order — HTTP DDoS rules first, then sensitivity rules tuned to the attack pattern, then rate limiting rules scoped to the specific endpoints under load, then Managed or Interactive challenges (Turnstile for APIs), and only last a bespoke incident rule.

Why a layer 7 flood behaves differently

A volumetric attack is won with capacity: more ingress than the attacker can fill. An HTTP flood — what many teams in Asia call a CC attack — is won with classification, because every individual request is well-formed. It opens a TCP connection, speaks HTTP correctly, and asks for a page your site legitimately serves. There is no malformed packet to filter and no threshold of bytes to absorb.

That difference drives everything else. Adding bandwidth to a layer 7 flood does nothing. What helps is answering one question per request: is this a real user, and is this request worth serving? The rest of this piece is about building that answer in the right order.

Four signals that tell you it is a layer 7 flood

Signal	What you look for	Why it matters
Divergence from the business curve	Requests climb while orders, signups or sessions stay flat	The cheapest reliable detector — real growth shows up in business metrics too
Concentration	Traffic clusters in a few ASNs, countries, paths or user agents	Legitimate audiences are diffuse; floods are not
Expensive endpoints	Calls concentrate on search, export, login or report generation	Attackers target high-cost paths because that is where a small volume hurts most
Behavioural mismatch	No page-to-page progression, no static asset requests, no referrers	Real sessions fetch assets and move; scripted ones do not

The fourth is the most diagnostic and the least instrumented. A session that requests /api/search repeatedly but never fetches a CSS file is not a user.

The order of mitigation that actually works

1. Stop the bleeding, then remove the emergency control. Under Attack Mode is documented as one of the last resorts, inserting an interstitial of roughly five seconds and distorting your analytics. Use it to buy minutes, then revert — leaving it on converts an attack into a self-inflicted outage.

2. Put caching in front of the origin. For most sites this is the single highest-leverage change: a flood aimed at pages that can be served from the edge never reaches your infrastructure. Cache rules let you match on path, query string, header or cookie and serve from cache without touching the origin.

3. Let the automated layer do the broad work. The HTTP DDoS managed ruleset runs on all plans. On lower plans you get one override and cannot customise its expression; the default sensitivity triggers at 1,000 errors per second, and on Pro, Business and Enterprise mitigation additionally requires the error rate to reach roughly five times your normal level. Sensitivity levels (High/Medium/Low/Essentially Off) belong to this ruleset — tune it, but know that it is a coarse instrument by design.

4. Write targeted rules for what you saw. WAF custom rules are where the signal from step “four signals” becomes policy: match the concentrated ASN, the abused path, the missing referrer. Rule counts are 5 / 20 / 100 / 1,000 by plan, and regular expressions require Business or above.

5. Apply rate limiting where volume still hurts. Rate limiting rules: 1 on Free, 2 on Pro, 5 on Business, 100 on Enterprise (per contract). Counting periods range from a fixed 10 seconds on Free to configurable windows up to 65,535 seconds on Enterprise; mitigation timeouts from 10 seconds to a day. Counting characteristics matter more than the count: IP only on Free and Pro, richer keys from Business, and query/host/header/cookie/ASN/country/path/JA3-JA4 with the Advanced Rate Limiting add-on on Enterprise.

6. Protect the expensive paths in the application. Turnstile is free, but server-side validation is mandatory and a token is valid for 300 seconds and single-use. Pair it with queues and graceful degradation on search, export and report endpoints so that even a successful flood degrades service rather than ending it.

Layered mitigation

Cloudflare capabilities vs. what your application must own

Item	What Cloudflare provides	What your application must do
Broad automated detection	HTTP DDoS managed ruleset on all plans	Decide sensitivity; accept that one override is coarse on lower plans
Targeted blocking	WAF custom rules, plan-limited in count; regex from Business	Maintain the rule set from real incident signals, not guesses
Rate control	Rate limiting rules; per-data-centre counters, mitigation delay of seconds	Authoritative quotas on expensive endpoints
Cache absorption	Cache rules matched on path, query, header, cookie	Make responses cacheable: correct headers, no per-user HTML in shared paths
Human verification	Turnstile — free; server-side validation mandatory; token 300 s, single use	Wire it into login, search and export flows
Graceful degradation	—	Queues, timeouts and a reduced-mode path for expensive operations

Boundaries and non-applicable cases

• Rate limiting cannot express an exact quota. It is documented as not designed to let a precise number of requests through, counters accumulate per data centre, and mitigation applies after a delay of a few seconds. If you need a hard ceiling per account or per API key, count it in the application.
• Caching only helps what is cacheable. A flood on personalised, per-user HTML will not be absorbed by the edge. If every response is unique, layer 1 is unavailable and you must compensate in layers 3–6.
• Challenges cost real users something. Managed and interactive challenges add friction; applying them to a path used by partners or crawlers has a cost. Scope them to what is actually under attack.
• The automatic ruleset will not catch a low-and-slow flood. Below roughly 1,000 errors per second and without an error-rate spike, the default thresholds are not met. Slow attacks need your own rules and rate limits, not the managed layer.
• Do not leave emergency controls on. Under Attack Mode pauses access and distorts analytics; it is a break-glass control with an owner and a revert step, not a configuration.

FAQ

Is an HTTP flood the same as a DDoS attack? It is one class of DDoS attack, and the one that behaves least like the stereotype. Volume is low, requests are valid, and the mitigation is classification rather than capacity. Many teams buy capacity and are then surprised that a modest request rate still takes the site down.

Will upgrading the plan fix it? Partly. More rate limiting rules, better counting keys, more WAF rules and regex support are genuinely useful. But if your expensive endpoints are uncached and unthrottled in the application, a bigger plan moves the breaking point rather than removing it.

Where should we start with almost no budget? Free gives you one rate limiting rule with IP-only counting and a fixed 10-second period, five WAF custom rules, and the automatic HTTP DDoS ruleset. Spend that budget on caching the paths under attack and on one well-chosen rate limit — not on trying to make the free tier behave like Enterprise.

How do we know when the attack is over? Watch the same four signals in reverse: request volume returns to the business curve, concentration in the anomalous ASN or path disappears, and static asset requests come back. Turn the emergency controls off then, not when the alert stops firing.

Related reading

• How to Choose DDoS Protection for Global Businesses
• Can a CDN Protect Your Website from DDoS Attacks?
• How to Choose an Enterprise Web Application Firewall
• Application security solution