What is an HTTP Flood DDoS Attack?

What is an HTTP flood DDoS attack?

An HTTP flood is a Layer-7 (application-layer) DDoS attack where the attacker sends massive volumes of HTTP GET or POST requests to a target web server. Each individual request looks legitimate — properly-formed HTTP, realistic user-agent header, plausible URL — which makes HTTP floods difficult to filter without blocking real users in the process. HTTP floods are the most common L7 DDoS attack pattern: simple to execute, hard to defend against, and disproportionately destructive relative to the bandwidth consumed.

Unlike volumetric (Layer 3/4) attacks that saturate network bandwidth with raw packet floods, HTTP floods exhaust server-side resources: web server worker pools, database connections, application memory, and downstream API quotas. A botnet of 5,000-10,000 nodes hammering an expensive endpoint at 5 requests/second per node — 25,000-50,000 RPS aggregate — can take down a typical mid-size SaaS application without exceeding the bandwidth a single residential broadband user would use.

How HTTP flood attacks work

The attacker controls a botnet — a network of compromised devices: hacked browsers, IoT devices (cameras, routers, smart appliances), or rented cloud instances purchased on darkweb forums for $5-50/hour for short attacks. Each bot in the network sends HTTP requests to the target with these characteristics:

• Properly-formed HTTP. Real HTTP/1.1 or HTTP/2 requests with valid headers — Host, User-Agent (often spoofed to look like Chrome/Safari/Firefox), Accept, and so on. Anything that fails basic HTTP parsing gets dropped at the WAF anyway.
• Distributed source IPs. Requests come from thousands of geographically dispersed IPs — typically residential IP space rented from compromised devices, ISP CGNAT pools, or cloud providers' transient IP ranges.
• Targeted endpoint selection. Smart attackers target the most expensive endpoints: /search?q=..., /api/recommendations, the dynamic homepage with no caching, login forms that hit the auth database. Each request triggers significant CPU and database work.
• Cache-busting variation. Append unique query parameters or randomize fragments to force every request through the CDN to origin: /search?q=test&_cb=12345, /search?q=test&_cb=12346, etc. CDN caching becomes useless.

HTTP flood vs other L7 attack patterns

HTTP flood is the most common L7 attack but several variants and adjacent patterns exist:

• HTTP flood (this entry): High volume of fully-formed HTTP requests. Can be GET-flood (read-heavy endpoints) or POST-flood (write-heavy endpoints — often more damaging because writes hit the database).
• Slowloris: Opens many TCP connections, sends partial HTTP headers slowly, never finishes. Connections stay open consuming server slots; legitimate users can't connect because the connection pool is exhausted.
• RUDY (R-U-Dead-Yet): Slow POST attack — sends valid POST headers, then dribbles the body in tiny chunks for hours. Web server keeps the connection alive waiting for the body to complete.
• Recursive GET: Hammers expensive recursive endpoints (search-with-filters, complex aggregations) that touch many backing services per request.
• Form-spam flood: POST-floods to forms (login, signup, contact) that trigger downstream side effects: emails sent, new user records, log entries.

Why HTTP floods are dangerous

• Hard to distinguish from real users. A spike in homepage GETs from thousands of distinct IPs looks like a viral hit OR an HTTP flood. Defenders have to choose: block aggressively and lose real users, or be permissive and stay vulnerable.
• Resource amplification. A 1 KB HTTP request can trigger a 100 ms database query plus a 200 ms recommendation call plus a 50 ms downstream API hit. Each byte of attack input becomes 100+ bytes of server-side work.
• Cost amplification. If you autoscale on traffic, an HTTP flood scales your infrastructure bill upward. The attacker pays for a botnet; you pay AWS for the workers serving the attacker.
• Cascading failures. When the worker pool is saturated, real users start timing out. Their browsers retry, increasing load further. The application can fail before the attack reaches "saturation" in any traditional sense.

How to defend against HTTP floods

WAF with rate limiting

A modern WAF (Cloudflare, AWS WAF, Akamai, Fastly) sits in front of origin and applies rate limits per IP, per session, per endpoint. Most managed WAF rule sets recognize common bot fingerprints and HTTP flood patterns automatically. Tune the rate limit to your normal peak traffic plus 50% headroom — anything above that triggers the WAF.

JavaScript challenges and CAPTCHAs

When the WAF detects a flood pattern, serve a JavaScript challenge or CAPTCHA. Most botnets don't run JavaScript or solve CAPTCHAs at scale; real browsers do. Cloudflare's "Under Attack" mode automates this. Modern challenges are invisible to most legitimate users.

Aggressive caching

Cache-busting attacks fail against well-cached endpoints. Set Cache-Control: max-age on all GET endpoints. Use a CDN with high cache hit ratios. For dynamic endpoints, consider stale-while-revalidate to serve cached content while origin recovers.

Application-level rate limiting

Defense in depth. Even with a WAF, your application should rate-limit at the session/user level. A WAF catches IP-based floods; application rate limits catch attackers who rotate through residential IPs but coordinate against the same accounts.

Prepare for failover

Identify your most expensive endpoints and have a circuit-breaker plan. If /api/recommendations is the bottleneck during attacks, configure it to return a cached fallback or a simple error response when load exceeds X requests/second. Better to degrade one feature than collapse the whole site.

Monitor and alert proactively

You should know about an HTTP flood before customers do. Alert on: request rate above 2x the rolling baseline, error rate above 1%, p95 latency above SLO. Automated mitigation (WAF auto-activate) closes the gap from "detected" to "mitigated" but proactive monitoring catches attacks the WAF doesn't.

FAQ: HTTP Flood DDoS Attacks

How big does an HTTP flood need to be to take a site down?

Smaller than people think. 25,000-50,000 RPS targeting expensive endpoints can overwhelm a typical mid-size SaaS application's worker pool. Attackers don't need millions of requests per second — just enough to saturate your most expensive endpoints faster than autoscale can react.

Will Cloudflare's free plan stop HTTP floods?

Partially. The free plan provides basic DDoS protection (mostly Layer 3/4) and "Under Attack" mode for L7 attacks. Persistent or sophisticated HTTP floods need the Pro/Business plan with managed WAF rules, rate-limiting controls, and bot management.

How do I distinguish an HTTP flood from a viral traffic spike?

Look at the traffic shape: viral spikes are concentrated on one or a few URLs (the page that went viral) with diverse user-agents, geography, and referrers. Floods are uniform: same URLs hit by same user-agents from same regions, no organic referrers. Conversion rate also helps — viral traffic converts; flood traffic doesn't.

Can I run a load test that mimics an HTTP flood?

Yes — that's exactly what stress testing does. Use LoadFocus to run JMeter or k6 scripts at high concurrency from cloud regions, hitting your expensive endpoints with realistic request shapes. Validates that your rate limits, CDN, and autoscale work BEFORE an attacker tests them. The difference: load tests respect rate limits and stop on signal; attackers don't.

Should I rate-limit by IP or by session?

Both. IP rate-limiting catches attacks from single sources. Session/user rate-limiting catches distributed attacks coming from thousands of IPs but coordinated against your endpoints. Layer them — neither alone is sufficient.

What's the cost of being unprepared for an HTTP flood?

Three buckets: direct (downtime cost — lost transactions, SLA penalties), indirect (autoscale cost — your infrastructure bill multiplied while serving attack traffic), reputational (customer churn after public outages, ranking drops if Googlebot can't crawl during attacks). For a typical e-commerce site, a 4-hour outage during peak traffic costs five figures minimum.

How LoadFocus helps you prepare for HTTP floods

LoadFocus runs scriptable JMeter and k6 load tests at scales that mimic HTTP flood attack patterns: high RPS, expensive endpoint targeting, cache-busting variations. Run a stress test from loadfocus.com/free-load-test against your staging environment to validate that your rate limits, CDN caching, and autoscale work before an attacker stress-tests them for you. Pair with API monitoring from 25+ regions to catch real attacks early.