An HTTP(S) flood attack is a denial-of-service attack that overwhelms a web application or web server with a large volume of HTTP or HTTPS requests. The attacker tries to exhaust server resources, application threads, or upstream capacity so legitimate users cannot be served.
What an HTTP(S) flood attack does
An HTTP(S) flood attack is not about breaking encryption or exploiting a single bug. It turns ordinary-looking web traffic into a denial-of-service event by driving so many requests that the application, reverse proxy, load balancer, or origin server runs out of capacity to answer real users.
The traffic often resembles normal browsing at the protocol level, which makes the attack harder to distinguish from legitimate demand. That is why HTTP flood attacks sit at the boundary between volume abuse and application-layer exhaustion, and why they can be effective even when the network itself is not saturated.
Why HTTP and HTTPS floods are effective
Web stacks usually do more work per request than people expect. A single request can trigger TLS termination, authentication checks, routing, template rendering, cache lookups, database access, or calls to upstream services. When enough requests arrive at once, the bottleneck is often worker threads, connection pools, application logic, or origin capacity rather than raw bandwidth.
HTTPS adds more computational cost than plain HTTP because the server must also handle session setup and encryption-related processing. Even when caching helps, attackers can bypass cache efficiency by varying paths, headers, query strings, or request bodies so the origin must process each request as if it were new.
How organisations recognise exposure
Exposure starts with the public attack surface: internet-facing sites, APIs, login endpoints, search functions, and any path that forces expensive backend work. If a service can be reached directly from the internet, and if it has no edge protection, rate controls, or upstream shielding, it is a candidate target for this attack pattern.
Teams should also look for hidden fragility in application design. Pages that trigger database joins, expensive search queries, file generation, or third-party lookups can become disproportionate load multipliers. A site may appear robust under ordinary traffic while still failing quickly once a flood concentrates on one costly endpoint.
What effective defence looks like
The right defence is layered, not singular. Edge filtering, CDN absorption, WAF rules, rate limiting, request shaping, autoscaling, and origin hardening each address a different part of the problem. For broader context on mitigation patterns, see the DDoS Protection Guide.
Capacity controls need to be paired with application discipline. Timeouts, concurrency limits, cached responses, graceful degradation, and protection for expensive routes reduce the chance that one burst of traffic cascades into a full service outage. The goal is not only to absorb traffic, but to preserve useful service for real users under stress.
How incident teams investigate and recover
During an attack, the key question is whether the service is failing because of request volume, expensive request patterns, or a separate underlying weakness. Logs, edge metrics, origin CPU and memory, connection counts, queue depth, and latency by endpoint help distinguish a flood from a bug, bot spike, or upstream dependency failure.
After recovery, teams should review whether the event exposed a brittle endpoint, an underprovisioned tier, or missing rate controls. If the flood relied on specific URLs, forms, or API methods, those paths may need redesign rather than just temporary filtering. For structured recovery planning, the DDoS Response Playbook is a useful reference point, and the CISA cyber threat advisories page is the authoritative federal source for current threat context.
Risk and Threat Considerations
HTTP(S) flood attacks are dangerous because they exploit the fact that a service must usually do some real work before it can decide whether a request is legitimate. Even when the attacker cannot compromise the server, they can still deny service by exhausting threads, queues, CPU, memory, or upstream dependencies.
Failure mechanism: The attack drives request concurrency, handshake cost, or expensive application paths beyond the service’s handling capacity, causing latency spikes, dropped connections, and failed legitimate requests.
Impact: The business consequence is partial or total unavailability, but the operational impact can extend to failed logins, stalled checkout flows, broken dashboards, or collateral pressure on shared infrastructure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-8 — Audit Log Management | Flood attacks are detected and investigated through request and origin logging. |
| CIS-12 — Network Infrastructure Management | HTTP(S) floods often require edge filtering, segmentation, and traffic shaping at ingress. | |
| CIS-13 — Network Monitoring and Defense | This attack is an availability threat that depends on rapid detection and traffic defence. | |
| Recommendation — Centralise and review logs to spot request spikes, error bursts, and abusive patterns quickly. Harden ingress paths and filter abusive traffic before it reaches origin services. Monitor traffic baselines and deploy DDoS defenses to absorb or block flood traffic. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Protected endpoints and request paths depend on controlling who can consume service resources. |
| DE.CM-01 — Networks and Network Services Are Monitored to Find Potentially Adverse Events | HTTP flood attacks are identified through monitoring traffic volume, latency, and service degradation. | |
| Recommendation — Restrict and validate access paths so unauthorised request volume cannot consume protected capacity. Baseline normal request behaviour and alert on sustained volume or latency anomalies. | ||
| OWASP ASVS | V4 — API and Web Service | HTTP(S) flood attacks commonly target web services and APIs whose request handling must be controlled. |
| V16 — Security Logging and Error Handling | Detection and recovery depend on logs and error signals that reveal request abuse and service exhaustion. | |
| Recommendation — Apply API and web-service controls that limit abusive request rates and expensive operations. Log request anomalies and service failures so flood behaviour is visible during an incident. | ||
| OWASP API Security Top 10 | API4 — Unrestricted Resource Consumption | HTTP flood attacks are a direct form of resource exhaustion against web and API endpoints. |
| API8 — Security Misconfiguration | Missing rate limits, weak edge protections, and poor caching make HTTP flood attacks easier. | |
| Recommendation — Set quotas, throttles, and cost limits so a request storm cannot exhaust shared resources. Harden edge and origin settings so exposed endpoints cannot be overwhelmed by simple traffic bursts. | ||
| NIST SP 800-53 Rev 5 | SC-5 — Denial of Service Protection | The control directly addresses availability threats from traffic floods and service exhaustion. |
| Recommendation — Deploy denial-of-service protections that preserve availability under attack conditions. | ||
Practitioner Guidance
Why practitioners should care: Treat HTTP(S) flood resilience as a service-design requirement, not just an upstream network problem. A site that looks healthy in normal testing can still fail if one expensive endpoint becomes the focus of a concentrated request storm.
What to watch for: Sudden growth in requests per second, unusually uniform request patterns, high error rates on a small set of URLs, and origin saturation that appears before bandwidth is fully consumed are strong indicators that the service is being pushed into application-layer exhaustion.
Practitioner takeaway: Defences work best when the edge, the application, and the recovery process are designed together, so the service can shed load without collapsing under it.
Related resources from NHI Mgmt Group
- How should security teams mitigate HTTP/2 CONTINUATION Flood attacks in exposed services?
- What are the signs that an HTTP/2 stack is vulnerable to CONTINUATION Flood attacks?
- What happens when HTTP/2 CONTINUATION Flood protection is missing from a web service?
- Why does exposing high-privilege MCP tools over HTTP create a much larger attack surface than stdio-based transports?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org