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

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.