RST_STREAM flooding is a denial-of-service attack against HTTP/2 connections that abuses the RST_STREAM frame. An attacker sends many rapid stream reset commands to exhaust server, proxy, or intermediary resources by forcing excessive stream state changes and processing work.
How RST_STREAM Flooding Works
RST_STREAM flooding is a denial-of-service technique against HTTP/2 that abuses stream reset handling rather than payload volume. The attacker’s goal is to force repeated state transitions, bookkeeping, and request-processing overhead until the target spends disproportionate resources on connection management.
Because HTTP/2 multiplexes many streams over one connection, reset traffic can be especially expensive when servers, proxies, load balancers, or other intermediaries must keep tracking stream lifecycle changes at high speed. The protocol itself is not broken by definition, but implementations that accept resets too readily or process them inefficiently can be pushed into a resource spiral.
Why It Strains HTTP/2 Infrastructure
RST_STREAM flooding is dangerous because the cost is often asymmetric: a small amount of attacker traffic can trigger repeated processing in components that terminate, inspect, or forward HTTP/2. That makes the issue relevant to origin servers, reverse proxies, and any intermediary that maintains per-stream state.
The practical concern is not only bandwidth. CPU, memory, thread pools, connection tables, and stream bookkeeping can all become bottlenecks when many resets arrive in rapid succession. In layered deployments, a single noisy client may also amplify work across multiple hops, which is why protocol-aware infrastructure needs to treat reset behavior as a resource-control problem, not just a transport detail.
For protocol-specific hardening guidance, NHIMG’s HTTP/2, HTTP/3 and QUIC Security Guide covers rapid reset and related HTTP/2 defenses in more depth.
How Teams Assess Exposure
Exposure usually starts with identifying every HTTP/2 endpoint in the path, including edge proxies, CDN layers, ingress controllers, API gateways, and application servers. If any of those components speak HTTP/2 or translate it downstream, they should be treated as part of the attack surface.
Assessment should also focus on whether the organization can observe reset rates, stream churn, and connection-level anomalies. Vendor advisories and protocol implementation notes matter here because the operational risk often depends on how a specific product handles malformed or excessive frame behavior. In practice, teams should verify whether HTTP/2 is enabled where it is truly needed and whether intermediary components have any documented protections against reset abuse.
Established security control catalogs also support this kind of inventory and monitoring work. NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference for access, monitoring, and integrity-oriented safeguards around exposed services.
Mitigation, Detection, and Recovery
Mitigation is usually a combination of protocol limits, rate controls, and careful traffic management. Where possible, organizations should apply server and proxy settings that constrain excessive reset activity, enforce sane concurrency behavior, and reduce unnecessary per-stream work. When patching or tuning is not immediately possible, compensating controls such as upstream filtering, connection throttling, or temporary feature restriction can reduce the blast radius.
Detection should look for spikes in RST_STREAM frames, unusually high stream turnover, and disproportionate CPU or event-loop activity relative to request volume. After an incident, teams should review whether the attack caused secondary instability, especially in shared reverse proxies or multiplexing gateways that may have degraded other traffic at the same time. If the flood was severe enough to affect availability, response should include confirming that the service did not silently enter a degraded state that outlasted the attack window.
HTTP/2 hardening also benefits from adjacent control thinking in broader web and infrastructure standards. OWASP API Security Top 10 is relevant where HTTP/2 fronts APIs and overloaded intermediaries can create availability failure modes.
Risk and Threat Considerations
RST_STREAM flooding is primarily an availability risk, but it can also become a resilience and concentration issue when many services share the same HTTP/2 terminator or proxy tier. The more traffic is consolidated through a single component, the more attractive that component becomes as a denial-of-service target.
Failure mechanism: The attacker sends repeated stream reset commands that force the target to allocate processing cycles to state changes, cleanup, and protocol handling until useful work is crowded out.
Impact: The result can be elevated latency, request failures, proxy instability, or full service degradation across all traffic that depends on the affected HTTP/2 path.
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 NIST CSF 2.0, NIST SP 800-53 Rev 5 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 — Monitoring for Anomalies and Events | RST_STREAM flooding is detected through anomalous reset and stream-churn patterns. |
| Recommendation — Monitor HTTP/2 reset rates and stream churn for anomaly spikes. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Reset-flood detection depends on reviewing logs and telemetry for abnormal protocol activity. |
| SC-5 — Denial of Service Protection | The attack is a denial-of-service condition created by excessive protocol work. | |
| Recommendation — Review HTTP/2 logs and telemetry for abnormal reset activity. Apply DoS protections at proxies and servers that terminate HTTP/2. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | RST_STREAM flooding is a network-facing availability attack that benefits from traffic monitoring and filtering. |
| Recommendation — Inspect edge traffic for abusive HTTP/2 reset patterns. | ||
| OWASP API Security Top 10 | API4 — Unrestricted Resource Consumption | The flood forces excessive resource use in HTTP/2-facing APIs and intermediaries. |
| Recommendation — Limit protocol-driven resource exhaustion on API gateways and edge services. | ||
Practitioner Guidance
What to watch for: Treat unusually high reset rates as a service health signal, not just a protocol quirk. If resets are rising while business traffic stays flat, the issue may be deliberate abuse rather than an application bug.
Governance implication: Ownership of HTTP/2 protection should sit with the teams that run the edge, proxy, and application layers together, because the weak point is often in the handoff between them. Clear responsibility for protocol limits, telemetry, and incident response is more important than any single product setting.