Security teams detect HTTP flood by identifying large numbers of requests to web applications, often to a small set of pages or endpoints, with abnormal source diversity or request repetition. Watch for rising error rates, latency, and session churn. Correlate application logs, reverse proxy data, and rate-limit events to distinguish abuse from legitimate surges.
How to recognise HTTP flood patterns in the traffic stream
http flood detection starts with the shape of the request pattern, not just total volume. A real attack often concentrates on a narrow set of pages or endpoints, repeats the same request shapes at high frequency, and creates disproportionate load compared with normal user behaviour. The most useful signals are request concentration, source diversity that does not match the audience, and repetition that looks machine-driven rather than interactive.
Operationally, the question is whether the traffic is merely busy or actually exhausting application capacity. That distinction usually shows up in the application layer first, through rising response times, elevated 4xx or 5xx rates, and session churn that suggests users are being forced to retry or restart. If the same endpoints are being hit across many source IPs or user agents, the request pattern may be distributed rather than simple high-rate traffic.
Detection improves when teams separate edge telemetry from application telemetry. Reverse proxy logs, load balancer metrics, rate-limit counters, and origin application logs each reveal different parts of the event. A request spike that looks manageable at the perimeter may still be harmful if it is expensive to process inside the web stack, so correlate request rate with backend latency and error behaviour before deciding it is benign.
What distinguishes an HTTP flood from a legitimate surge
Legitimate surges usually have a business explanation and a more organic distribution of behaviour. Users tend to browse more than one page, arrive through recognisable campaigns or release events, and show mixed timing across sessions. HTTP floods often compress activity into a few hot endpoints, reuse the same path patterns, and sustain pressure in a way that outlasts normal interest spikes.
Another practical distinction is client diversity. A healthy surge can still have many unique clients, but those clients typically vary in geography, device, cookie state, and navigation sequence. Flood traffic may appear diverse at the IP level while still being repetitive at the request level, so teams should look beyond source count and inspect headers, session reuse, referers, and the ratio of successful page views to repeated retries.
For teams handling web-facing services, a broader DDoS playbook helps because HTTP flood is one form of application-layer denial of service. NHIMG’s DDoS Protection Guide covers the wider response context, including how application-layer floods fit alongside volumetric and protocol attacks.
Which telemetry is most useful for early detection and triage
The most reliable early indicators are the ones that connect request behaviour to service impact. Watch for bursts against login, search, checkout, API gateway, or other resource-heavy endpoints, especially when they coincide with rising CPU, thread pool pressure, cache misses, queue depth, or upstream timeout events. A flood is often easiest to confirm when request rate, latency, and error rate move together rather than in isolation.
Security teams should also preserve enough context to distinguish attack traffic from caching artefacts or broken client behaviour. Correlating web logs with CDN, WAF, and reverse proxy records makes it easier to see whether the same requests are being retried, whether particular cookies or sessions are failing, and whether rate limiting is suppressing the load or merely delaying the impact. If the request pattern shifts when limits are applied, that is a strong clue that the traffic is intentional rather than accidental.
HTTP-specific hardening signals can make this triage faster. The Security Headers Guide is useful where teams want to understand how HTTP-layer controls, cookies, and browser-facing protections fit into the broader web control surface.
Risk and Threat Considerations
HTTP floods are risky because they target the part of the stack that is often hardest to absorb cheaply, the application tier. Even when bandwidth is available, a high-rate request pattern can consume worker threads, saturate databases, or trigger cascading retries that amplify load across dependent services.
Failure mechanism: The attacker or abusive client sends many application-valid requests, often concentrated on expensive pages or endpoints, until the service spends more time processing noise than serving genuine users.
Impact: Users experience slow responses, failed sessions, and intermittent outages, while defenders may misread the event as a simple traffic spike until backend metrics and request repetition reveal the pattern.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Networks and physical devices are monitored to detect cybersecurity events | HTTP flood detection depends on continuous monitoring of web traffic and service anomalies. |
| DE.CM-08 — Vulnerability scans are performed | Application-layer flood hunting benefits from validating exposed endpoints and service exposure. | |
| Recommendation — Monitor web traffic and service telemetry for abnormal spikes and degraded response patterns. Validate exposed endpoints and service exposure so noisy traffic can be assessed in context. | ||
| MITRE ATT&CK | T1499 — Endpoint Denial of Service | HTTP flood is a denial-of-service pattern that exhausts application resources. |
| Recommendation — Map repeated request bursts to denial-of-service patterns and hunt for service exhaustion indicators. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Correlating logs is central to detecting application-layer floods and separating them from normal surges. |
| Recommendation — Centralise and review web, proxy, and application logs for repeated request patterns. | ||
| OWASP API Security Top 10 | API4 — Unrestricted Resource Consumption | Flood traffic often abuses expensive application paths until resources are exhausted. |
| Recommendation — Rate-limit and monitor resource-heavy endpoints to prevent abusive consumption. | ||
Practitioner Guidance
What to verify: Confirm that the same endpoints, headers, and session patterns are repeating before escalating to mitigation. If the traffic is spread across many pages with normal navigation behaviour, treat it differently from a concentrated flood against one or two expensive paths.
Decision rule: If latency, error rate, and rate-limit events rise together, prioritise application protection and traffic shaping over waiting for a perfect attribution answer. If only raw request volume rises without service impact, keep observing and compare it to historical campaign traffic.
What practitioners underestimate: HTTP flood detection fails when teams focus only on source IP count or only on WAF hits. The better test is whether the request pattern is causing disproportionate work inside the application and whether that work is becoming user-visible.
Practitioner takeaway: The best detection signal is not request volume alone, but repeated application-layer behaviour that creates measurable service degradation.