What is HTTP Flood? How to Mitigate Layer 7 DDoS Attacks

An HTTP flood attack is a Layer 7 (application layer) DDoS attack that overwhelms a web server by sending large numbers of HTTP GET or POST requests. Unlike volumetric attacks that saturate bandwidth, HTTP floods exhaust server-side resources—CPU, memory, database connections, and application threads—using requests that appear legitimate to network devices.

Last updated: 2026-08-24

TL;DR: HTTP floods target web application resources rather than network bandwidth. An attacker sends millions of valid HTTP requests per second; each request triggers server-side processing—database queries, cache lookups, and response rendering—that consumes CPU and memory. HTTP floods bypass traditional network-layer DDoS defenses and require application-aware detection through WAF, rate limiting, and behavioral analysis.

How HTTP Floods Work

HTTP floods use a distributed network of bots to send HTTP requests at high volume. Each request is syntactically valid and uses legitimate HTTP methods, headers, and URLs. Web servers process each request just as they would process a request from a real user.

GET flood:

GET /products?category=electronics&page=1 HTTP/1.1
Host: target.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml
Accept-Language: en-US,en;q=0.9
[Sent from thousands of bots simultaneously]

POST flood:

POST /search HTTP/1.1
Host: target.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 45

query=laptop&filters=brand,price&sort=relevance
[Each request triggers database query]

Why POST floods are more damaging than GET floods:

POST requests typically trigger server-side operations—database writes, search queries, form processing—that consume more CPU and memory than serving cached GET responses. A single complex database query triggered by a POST request may consume 100x the resources of serving a static file.

HTTP Flood vs. Volumetric DDoS

Types of HTTP Flood Attacks

Simple GET flood: High-volume requests for static or cached resources. Less effective against well-optimized infrastructure with CDN caching, but can overwhelm origin servers directly.

Complex GET flood: Requests target non-cacheable URLs—unique query strings, session-specific pages, or URLs with random parameters that bypass CDN caching and require origin processing.

GET /products?id=83729&session=f8a3k2&rand=19283746 HTTP/1.1

POST flood: Targets endpoints that trigger database operations—login forms, search, checkout, comment submission.

HTTP/2 rapid reset attack (CVE-2023-44487): Exploits HTTP/2’s stream reset mechanism. An attacker opens HTTP/2 connections, sends request streams, and immediately cancels them with RST_STREAM frames. This forces servers to allocate and then release resources rapidly, at rates of millions of stream resets per second. In 2023, coordinated industry disclosures documented Layer 7 attacks reaching tens of millions of requests per second.

HTTPS flood: Targets HTTPS endpoints. TLS handshake processing consumes significant CPU at the server. HTTPS floods add cryptographic overhead on top of application processing.

Attack Scale Statistics

Source: public industry reports and coordinated CVE-2023-44487 disclosures.

Detection Signals

HTTP floods are harder to detect than volumetric attacks because individual requests are legitimate. Detection relies on pattern analysis across multiple signals:

Mitigation Strategies

1. Rate limiting per IP and per endpoint

Limit the number of requests per second from any single IP address. More precise: limit per endpoint (e.g., /login max 5 requests/minute per IP). Rate limits should be lower for sensitive endpoints (authentication, payment).

2. CAPTCHA and browser challenges

Challenge suspicious clients with a browser integrity check (JavaScript challenge) or CAPTCHA before serving the request. Bots typically cannot complete JavaScript challenges; legitimate browsers complete them transparently.

3. WAF behavioral rules

WAF rules that correlate multiple signals—user-agent, TLS fingerprint, HTTP header order, request timing, and URL patterns—to distinguish bots from legitimate users. Rule sets like OWASP CRS include HTTP flood detection patterns.

4. Anycast and traffic distribution

Distribute traffic across many edge locations using anycast. A 71M RPS attack distributed across 300 edge locations becomes ~237K RPS per location—manageable with appropriate rate limiting.

5. HTTP/2 rapid reset mitigation

Apply patches from web server vendors (nginx, Apache, Envoy, Golang) released in October 2023 for CVE-2023-44487. Set limits on concurrent HTTP/2 streams per connection.

6. Bot management

Classify traffic as bots, human users, and crawlers. Block malicious bots while allowing legitimate search engine crawlers. Bot management systems use fingerprinting, behavioral analysis, and IP reputation.

Frequently Asked Questions

What is an HTTP flood attack? An HTTP flood is a Layer 7 DDoS attack that sends large volumes of HTTP GET or POST requests to overwhelm a web server’s application resources. Unlike volumetric attacks, HTTP floods do not require large bandwidth—they exhaust CPU, memory, and database connections using individually valid HTTP requests.

How is an HTTP flood different from a volumetric DDoS attack? Volumetric DDoS attacks saturate network bandwidth with raw traffic volume (UDP floods, amplification attacks). HTTP floods target web application resources with valid HTTP requests at the application layer. A volumetric attack of 100 Gbps is visible on network monitoring; an HTTP flood of equivalent damage may use only 1 Gbps of legitimate-looking HTTP traffic.

Can a CDN stop an HTTP flood? A CDN reduces the impact of GET floods against cacheable content by serving responses from cache without reaching the origin. However, attackers craft requests with unique query parameters to bypass caching. POST floods always bypass the CDN cache. A CDN must be combined with WAF, rate limiting, and bot management to handle HTTP floods effectively.

What is the HTTP/2 rapid reset vulnerability? CVE-2023-44487 is a vulnerability in the HTTP/2 protocol where attackers open many streams and immediately cancel them with RST_STREAM frames. This forces servers to allocate and deallocate resources millions of times per second, causing extreme CPU exhaustion. The flaw was exploited to generate 71M RPS attacks in 2023 before patches were released.

How do attackers rotate user agents to evade detection? Attackers program bots to randomize HTTP headers including User-Agent, Accept-Language, and Accept-Encoding to mimic diverse browsers. More sophisticated attacks use real browser fingerprints obtained from scraped data. Detection relies on behavioral signals (request timing, session absence, URL patterns) rather than user-agent matching alone.

Does HTTPS protect against HTTP flood detection? HTTPS encrypts request content in transit, but TLS is terminated at the WAF or load balancer before content inspection. Protection at the application layer sees decrypted HTTP requests and applies WAF rules normally. HTTPS does not prevent detection—it adds TLS handshake load that can be used as a detection signal (high TLS handshake rates without completed requests).

What is the difference between an HTTP flood and a Slowloris attack? HTTP floods send requests as fast as possible, overwhelming the server with volume and processing load. Slowloris sends requests as slowly as possible, keeping connections open to exhaust the connection pool. Both target application layer resources but use opposite strategies—high volume versus connection exhaustion.

How many requests per second can a WAF handle? WAF capacity varies by vendor and deployment. Hardware-based WAFs typically handle 1–10M RPS. Distributed WAFs operate at platform scale because traffic is processed across global edge infrastructure rather than at a single point.

How to Implement on Azion

Azion’s WAF and DDoS Protection together address HTTP flood attacks at the application layer:

• WAF applies behavioral rules, rate limiting, and pattern-based detection to identify and block HTTP flood traffic
• DDoS Protection provides always-on Layer 7 DDoS mitigation alongside network-layer protection
• Bot Management classifies and blocks malicious bots generating HTTP flood traffic
• Edge Firewall enables custom rate limiting rules per URI, IP, and header combination
• WAAP combines all of the above in an integrated Web Application and API Protection solution

HTTP flood traffic is processed at the edge—distributed across hundreds of locations—before reaching your origin server.

Related Resources

• What Are Application Layer Attacks?
• What Is a DDoS Attack?
• What Is a Bot Attack?
• Azion WAF
• Azion WAAP

Sources:

• CISA. “HTTP/2 Rapid Reset Vulnerability, CVE-2023-44487.”
• IETF. “Hypertext Transfer Protocol Version 2 (HTTP/2).” RFC 9113. 2022.
• CVE-2023-44487. “HTTP/2 Rapid Reset Attack.” NVD, 2023.
• OWASP. “HTTP DoS.” OWASP Community Pages, 2024. An HTTP Flood attack is a Layer 7 (application layer) DDoS attack that floods a web server or API with a high volume of HTTP GET or POST requests, or through HTTP/2-specific vectors. Unlike volumetric attacks that saturate bandwidth, HTTP Flood exhausts server resources — threads, connections, CPU, and memory — using requests that may appear legitimate to network devices that do not inspect content.

How HTTP Flood attacks work

The impact of an HTTP Flood depends on the per-request cost on the server side. Requests to endpoints that query databases, execute business logic, make calls to external services, or render dynamic content can exhaust resources at relatively low volume. The attacker does not need to generate terabits of traffic — concentrating requests on expensive routes is enough.

The attack may use a botnet with many source IPs or a smaller set of clients that open multiple connections or streams. Detection requires pattern analysis, behavior, cost per route, and historical baseline — not just raw volume.

Taxonomy: HTTP Flood in context with other attacks

The OSI layer classification is a useful operational model, but it is not rigid. A single attack may exploit an application protocol, travel over TCP, and simultaneously pressure CPU, connection queues, and business logic. The table below uses operational categories to guide defense.

Routers and network controls typically act at Layers 3 and 4, applying policies by IP, port, protocol, volume, and flow behavior. Modern firewalls and proxies may offer additional inspection capabilities, but full HTTP request analysis typically requires a WAF, reverse proxy, or another component that terminates TLS.

HTTP Flood types

GET Flood

Sends HTTP GET requests at high volume against one or more server URLs. URLs that trigger database queries, dynamic page rendering, or heavy backend processing are preferred targets — each request consumes more resources than a static response. The goal is to occupy all available processing threads until the server stops responding.

POST Flood

Combines request volume with the cost of processing payloads. Authentication forms, search endpoints, and data-processing APIs are common targets — each POST request forces the server to parse the message body before responding. A POST Flood can have greater per-request impact than a GET Flood, meaning lower RPS volumes can produce a similar effect.

Cache bypass

An attacker may try to reduce cache efficiency by using random parameters, unique paths, or attributes that alter the cache key — such as ?cb=7f3a9 or ?ts=1687234561. The effect depends on the cache policy: some CDNs include query strings in the key, while others may ignore, normalize, or limit certain parameters.

When the attack is successful, cache misses increase and more requests reach the origin, raising its load. An abrupt drop in cache hit rate is a relevant signal, but should be correlated with configuration changes, deploys, campaigns, content mix shifts, and origin metrics before being classified as an attack.

HTTP/2 Rapid Reset

HTTP/2 Rapid Reset exploits HTTP/2’s stream multiplexing mechanism. In HTTP/1.1, persistent connections can carry multiple sequential requests, but the protocol does not offer native simultaneous multiplexing. HTTP/2 introduced independent streams that allow multiple concurrent requests over a single TCP connection.

The attack opens a stream with a HEADERS frame and closes it quickly with RST_STREAM. Depending on the implementation, the server, proxy, or load balancer may need to create state for the stream, process headers, update counters, apply limits, and handle the cancellation before releasing resources.

The impact does not require every request to reach the backend. The cost of creating and cancelling streams at high speed can be enough to pressure CPU and internal HTTP/2 stack structures. The core issue behind CVE-2023-44487 was the ability to bypass protections based solely on the maximum concurrent streams limit by opening and resetting streams rapidly to keep the active count low while accumulating work on the server.

Detection requires monitoring HTTP/2 protocol-specific metrics: a high ratio of RST_STREAM frames relative to completed streams, combined with high CPU consumption without proportional response traffic, is the characteristic pattern of this vector.

Operational signals: what to observe

Correlating multiple metrics is more reliable than any isolated indicator. The values below are illustrative — use a per-application, per-route, per-HTTP-method, per-region, and per-period baseline. An authenticated API may have a cache hit rate near zero under normal operation; a static content service may operate above 95%.

No single indicator confirms an HTTP Flood. Analysis must correlate network, TLS, HTTP, cache, application, and user behavior telemetry.

Alerts should detect meaningful changes relative to the historical pattern of that flow — not rely on fixed universal percentages.

Mitigation techniques

WAF with score-based detection

The WAF inspects HTTP requests at Layer 7 and can evaluate multiple factors: header anomalies, request frequency per IP, matching against known signatures, and source reputation.

Unusual, absent, or inconsistent headers can be used as additional signals, but must not block traffic in isolation. Evaluation must consider the endpoint type, the API contract, the profile of legitimate clients, and correlation with rate, identity, fingerprint, session, and behavior. Legitimate clients such as APIs, mobile apps, health checks, and backend-to-backend integrations may omit headers like Accept-Language or Referer for valid reasons.

WAF requires continuous tuning. Overly aggressive rules can block legitimate traffic; overly permissive rules fail to detect attacks. Per-application and per-endpoint behavior baseline is essential for calibration.

JA3/JA4 TLS fingerprinting

JA3 and JA4 are TLS fingerprinting signals based on Client Hello characteristics, such as versions, cipher suites, and extensions. They can help group clients with similar behavior and identify automation or known tools when correlated with other signals.

These fingerprints do not uniquely identify a user or bot. Legitimate clients can share the same signature, and sophisticated attackers can mimic browser fingerprints or use real browsers. Advanced bots can use Playwright, Puppeteer, Selenium, or mobile environments. Therefore, JA3/JA4 should contribute to a risk score alongside reputation, request rate, cookies, navigation behavior, identity, route accessed, and application signals.

JA4 is a more recent family of fingerprints, proposed to reduce some practical limitations of JA3, such as ordering variations in certain fields. Its availability, format, and usefulness depend on the security tool used.

Granular rate limiting per endpoint

Rate limiting can be applied per IP, prefix, session, credential, token, tenant, fingerprint, route, and behavior. IP-only limits can affect users behind NAT or CGNAT and are less effective against distributed botnets. The goal is to prevent abusive requests from advancing to the origin, but edge controls still need to be sized to absorb and classify the traffic.

Per-endpoint granularity is essential: a single threshold for the entire application poorly protects expensive endpoints (authentication, search, checkout) and may block legitimate traffic on high-volume endpoints. An HTTP 429 response informs the client to wait — and prevents the request from consuming origin resources, depending on the architecture.

Browser challenge and adaptive CAPTCHA

Browser challenges and CAPTCHAs can raise the cost of automation and reduce simple bot attacks. However, advanced bots can execute JavaScript or use real browsers, and challenges can affect accessibility, APIs, mobile apps, WebViews, and users with JavaScript blocked. Therefore, they should be applied adaptively, with false-positive monitoring and exception paths for trusted integrations.

Edge protection — controls before the origin

The most effective mitigation happens before requests reach the origin server. When HTTPS traffic is terminated at the edge, WAF, rate limiting, and API protection policies can be applied before selected requests are forwarded to the origin.

A distributed edge architecture can reduce the need for diversion to a single scrubbing center and bring mitigation closer to traffic sources. Latency impact depends on topology, routing, point-of-presence location, capacity, protocol termination, and applied policies.

Common mistakes when mitigating HTTP Flood

Blocking individual IPs during the attack: modern HTTP Floods use distributed botnets or multiple IPs. IP-only blocking is slow and ineffective. Use behavior-based rate limiting, fingerprinting, and access pattern analysis — which work even when IPs vary.

Applying the same rate limit to all endpoints: critical endpoints (authentication, API, checkout) have lower tolerance for abusive volume. Configure granular policies per URI with distinct thresholds based on processing cost.

Relying only on L3/L4 network firewall: network firewalls do not inspect HTTP content. A Layer 7 WAF is needed to detect HTTP Flood, cache bypass, and HTTP/2 Rapid Reset.

Using fixed thresholds for cache hit rate: a drop in cache hit rate can have many causes beyond an attack — deploy, TTL expiration, content mix change, campaigns. Calibrate alerts with the historical baseline of the route and correlate with other metrics.

Ignoring HTTP/2 protocol metrics: the RST_STREAM proportion is a specific indicator of Rapid Reset. Layer 7 observability tools should include HTTP/2 stream metrics alongside RPS.

Frequently asked questions

Are HTTP Flood and Layer 7 DDoS the same thing? HTTP Flood is one of the most frequent forms of application-layer DDoS, especially in web services and APIs. Other L7 attacks include low and slow attacks (Slowloris, R.U.D.Y.), DNS Water Torture, and API-specific exploits. HTTP Flood is distinguished by high request volume or high per-request cost, while low and slow operates with few connections intentionally kept open with minimal data. Prevalence varies by provider base and period analyzed.

How does JA3/JA4 TLS fingerprinting assist in detection? JA3/JA4 analyzes the Client Hello of the TLS negotiation — not HTTP headers. Each network library implementation tends to produce a specific combination of cipher suites, TLS extensions, and elliptic curves. This can help identify automation or known tools. These fingerprints are not unique identifiers — many legitimate users may share the same signature — and sophisticated bots can mimic browsers. They should be used as part of a risk score, not as an isolated criterion.

What makes HTTP/2 Rapid Reset dangerous? The client sends only two frames per attempt (HEADERS + RST_STREAM). Depending on the implementation, the server may need to create state for the stream, process headers, update counters, and handle cancellation before releasing resources — even though the result is discarded shortly after. CVE-2023-44487 demonstrated that implementations protected only by the concurrent stream limit were vulnerable to this rapid open-and-reset pattern. The result can be CPU saturation without proportional response traffic.

Why does HTTPS make mitigation harder? HTTPS encrypts request content. Network devices without TLS termination cannot inspect HTTP headers, URLs, or payloads. Effective HTTP Flood mitigation requires TLS termination at the edge, enabling the WAF to inspect the full request content. This is especially relevant for cache bypass detection and behavior analysis.

Does a CDN automatically protect against HTTP Flood? CDNs absorb load for cacheable content. HTTP Floods targeting dynamic endpoints — APIs, authentication, checkout — tend to bypass the cache by definition or use cache bypass techniques. Effective protection requires WAF and rate limiting integrated with the CDN for Layer 7 inspection before forwarding to the origin.

How do I distinguish an HTTP Flood from a legitimate load test? Legitimate load tests should have scope, time windows, responsible parties, origin, and methods agreed upon in advance. Investigation must correlate those records with traffic telemetry, authentication, origin, behavior, application impact, and configuration changes. Browser signals, cookies, and fingerprints can help but are not isolated proof of legitimacy or attack.

What is the operational difference between HTTP Flood and low and slow attacks? HTTP Flood tends to generate high request volume or high per-request cost, and may reuse persistent connections, HTTP/2, or HTTP/3. Low and slow attacks like Slowloris prioritize keeping connections or incomplete requests open for long periods with low data rate — saturating the connection pool without generating high RPS. Defenses also differ: rate limiting and WAF address HTTP Flood; connection timeouts and simultaneous session limits are more relevant for low and slow.

Technical references

• RFC 9113 — HTTP/2
• RFC 9114 — HTTP/3
• CVE-2023-44487 — HTTP/2 Rapid Reset Attack
• Google Cloud: HTTP/2 Rapid Reset DDoS attack

How to implement on Azion

Azion can compose a mitigation strategy for HTTP Flood and web application abuse, according to contracted products, published protocols, and configured policies.

1. Layer 7 controls at the edge: when HTTPS traffic is terminated at the edge, WAF, rate limiting, and API protection policies can be applied before selected requests are forwarded to the origin.
2. Rate limiting per route and behavior: limits can be configured per IP, URI, method, credential, session, tenant, or other criteria available in the policy, considering the cost and legitimate profile of each endpoint.
3. Automation detection: behavior signals, reputation, headers, sessions, and TLS fingerprints — when available — can help identify automated traffic. These signals should be used in combination to reduce false positives.
4. Observability: logs, request metrics, errors, cache, latency, and applied policies can support anomaly detection and control adjustment during an incident.

Effective coverage depends on the application architecture, TLS termination, enabled products, configured policies, and the traffic and attack profile.

Learn more in the Azion WAF documentation.