Join our Newsletter — 33% off our NHI Course
Home› Guides› HTTP/2, HTTP/3 and QUIC Security Guide: Rapid Reset,…
Guide Network Security

HTTP/2, HTTP/3 and QUIC Security Guide: Rapid Reset, QUIC Visibility and Hardening

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 27 October 2026 17 min read
On this page

HTTP/2 and HTTP/3 changed how web traffic is framed, multiplexed and transported, and both the attacks and the blind spots moved with them. HTTP/2 Rapid Reset (CVE-2023-44487) showed that a protocol feature working exactly as specified could drive record request floods, and HTTP/3 runs over QUIC on UDP, where most of the transport is encrypted and many inspection tools see very little. This guide covers the protocol-level risks of HTTP/2, HTTP/3 and QUIC, the server and proxy settings that limit them, the choice between allowing and blocking QUIC on corporate networks, and what to log. It is written for network, platform and application security engineers who run web servers, reverse proxies, load balancers and secure web gateways. Volumetric defence, scrubbing and CDN design are covered in the DDoS Protection Guide; this page goes deeper on the protocols themselves.

Key takeaways

  • Stream concurrency limits alone do not stop Rapid Reset. A reset stream stops counting against SETTINGS_MAX_CONCURRENT_STREAMS immediately, so servers must also count resets per connection and close abusive connections with GOAWAY.
  • Header handling is a recurring weak point. The 2024 CONTINUATION frame issues affected several major HTTP/2 stacks, so bound field section size, CONTINUATION frames per stream and header read time on every HTTP/2 listener.
  • QUIC encrypts almost everything after the first packets. RFC 9312 explains that middleboxes cannot modify QUIC packets and see far less than with TCP, so TLS inspection and many firewall features do not apply to HTTP/3.
  • Blocking UDP 443 is a legitimate policy, if done cleanly. Clients are expected to fall back to TCP, but random packet dropping breaks fallback; block whole flows instead.
  • 0-RTT early data is replayable. Accept it only for requests that are safe to replay, and support the Early-Data header and 425 Too Early status defined in RFC 8470.

What changes from HTTP/1.1

The HTTP semantics (methods, status codes, fields) are shared across versions. What differs is framing and transport, and that is where the new security properties come from.

PropertyHTTP/1.1HTTP/2 (RFC 9113)HTTP/3 (RFC 9114)
TransportTCP, optionally TLSTCP; in practice TLS with ALPN "h2" ("h2c" is cleartext and must not be used over TLS)QUIC over UDP (RFC 9000), TLS 1.3 integrated into QUIC
Requests per connectionOne at a time (pipelining rarely used)Many concurrent streams, multiplexedMany concurrent QUIC streams, no head-of-line blocking across streams
Header encodingPlain textHPACK compression with a dynamic tableQPACK (RFC 9204), using separate unidirectional streams for table state
DiscoveryDefaultNegotiated in the TLS handshake via ALPNAdvertised with Alt-Svc (for example Alt-Svc: h3=":443") or the ALTSVC frame, or tried directly
Default portTCP 80/443TCP 443UDP 443 by convention, but any UDP port is allowed
Visible to a network observerEverything without TLS; SNI and metadata with TLSTLS metadata and TCP headersVersion, connection IDs, flags; Initial packets are decryptable by any on-path device (revealing the ClientHello and SNI unless Encrypted Client Hello is used)
Replay exposureOnly with TLS 1.3 early dataOnly with TLS 1.3 early data0-RTT is a core QUIC feature, so replay handling matters more

RFC 9113 (June 2022) obsoletes RFC 7540 and RFC 8740. RFC 9114 (HTTP/3) and RFC 9000 (QUIC) are both Standards Track. Multiplexing is the root of most HTTP/2 denial-of-service issues: a single TCP connection can carry hundreds of requests, so per-connection limits and per-connection accounting matter more than per-request rules. For the TLS layer itself see the How TLS Works Guide and the TLS Server Configuration Baseline Guide.

HTTP/2 denial-of-service: Rapid Reset, CONTINUATION and resource exhaustion

Rapid Reset (CVE-2023-44487)

HTTP/2 lets a client cancel a stream with RST_STREAM. Only open or half-closed streams count towards the server's concurrency limit, so a client can open a stream, reset it, and open another straight away, without waiting for any response. The server still does the work of parsing each request and often dispatching it to a backend. Cloudflare reported attacks from 25 August 2023 that peaked just above 201 million requests per second from a botnet of about 20,000 machines; Google and AWS saw the same campaign and the issue was handled through coordinated disclosure. Cloudflare's own conclusion was that stream concurrency on its own cannot mitigate Rapid Reset. CISA added CVE-2023-44487 to the Known Exploited Vulnerabilities catalog on 10 October 2023 and reported exploitation from August to October 2023.

CONTINUATION flood (2024)

A header block can be split across a HEADERS frame and any number of CONTINUATION frames, and is complete only when END_HEADERS arrives. CERT/CC Vulnerability Note VU#421644 (April 2024) describes implementations that did not limit CONTINUATION frames per stream, so a server kept buffering or decoding while waiting for END_HEADERS, leading to memory or CPU exhaustion. Affected stacks listed by CERT/CC include Go net/http (CVE-2023-45288), nghttp2 (CVE-2024-28182), Apache HTTP Server (CVE-2024-27316), Apache Traffic Server (CVE-2024-31309), Envoy (CVE-2024-27919, CVE-2024-30255) and Node.js (CVE-2024-27983). Because the request never completes, these attacks may not appear in application access logs at all.

Attack classes and controls

Attack classWhat is abusedPrimary controlWhere to enforce
Rapid ResetRST_STREAM cancels streams before they count against limitsCount client resets per connection; close with GOAWAY (ENHANCE_YOUR_CALM) above a threshold; patched stackEdge proxy, CDN, load balancer, any HTTP/2 origin
CONTINUATION floodUnbounded header blocks awaiting END_HEADERSCap field section size and CONTINUATION frames per stream; header read timeout; patched stackEvery HTTP/2 listener, including internal gRPC services
Large or expensive headersHPACK/QPACK decoding cost, huge field sectionsSet SETTINGS_MAX_HEADER_LIST_SIZE (HTTP/2) or SETTINGS_MAX_FIELD_SECTION_SIZE (HTTP/3); reject with 431Server and proxy configuration
Control frame floodsFrames the peer must answer or process (SETTINGS, PING, empty frames)Per-connection frame rate limits; ENHANCE_YOUR_CALM on excessServer implementation and edge
Slow and idle connectionsConnections held open with minimal trafficIdle and keepalive timeouts, connections per client IPEdge and load balancer
QUIC amplification and handshake floodsSpoofed source addresses, server state before validation3x anti-amplification limit, Retry tokens under loadQUIC stack and edge

RFC 9113 defines ENHANCE_YOUR_CALM (0x0b) for exactly this purpose: the endpoint has detected that its peer is behaving in a way that might be generating excessive load. In ATT&CK terms these are T1499.002 Service Exhaustion Flood (application-layer) rather than T1498 Network Denial of Service; CAPEC-469 HTTP DoS is the matching attack pattern.

Hardening HTTP/2 servers and proxies

  • Patch first: Rapid Reset and CONTINUATION were fixed in the server code, not by configuration alone. Inventory every HTTP/2 implementation, including embedded ones: language runtimes (Go, Node.js), service meshes and sidecars (Envoy), API gateways, ingress controllers and appliances. CERT/CC's vendor table is the authoritative status list for the CONTINUATION issues.
  • Concurrent streams: RFC 9113 recommends SETTINGS_MAX_CONCURRENT_STREAMS of no less than 100. Lowering it is not a fix: Cloudflare temporarily reduced it to 64 during the attacks and restored 100 after legitimate clients broke.
  • Reset accounting: track RST_STREAM frames received per connection, and the ratio of reset to completed streams. Close connections that exceed a threshold with GOAWAY and ENHANCE_YOUR_CALM. Most major servers and proxies added this kind of control in their October 2023 patches; check the exact setting name in your product documentation.
  • Field limits: the initial value of SETTINGS_MAX_HEADER_LIST_SIZE is unlimited. Set an explicit limit (each field line counts 32 octets of overhead) and respond with 431 when it is exceeded. Apply the same in HTTP/3 with SETTINGS_MAX_FIELD_SECTION_SIZE, whose default is also unlimited.
  • Timeouts: set header read, idle and keepalive timeouts so incomplete requests are dropped. CERT/CC lists tighter timeouts and edge connection limits among the CONTINUATION mitigations.
  • Disable what you do not use: cleartext h2c upgrade on public listeners, HTTP/2 server push, and HTTP/2 on internal hops where HTTP/1.1 is enough. Fewer code paths means fewer exposures.
  • Protect GOAWAY debug data: RFC 9113 requires that logged debug data from GOAWAY frames is safeguarded against unauthorised access, because it can contain sensitive information.
  • Translation to HTTP/1.1: a proxy that accepts HTTP/2 and forwards HTTP/1.1 must reject malformed messages, including connection-specific fields such as Transfer-Encoding and field values containing CR, LF or NUL. Sloppy downgrading is a source of request smuggling. See the HTTP Request Smuggling Guide.

Where identity fits: gRPC runs over HTTP/2, so internal service-to-service traffic authenticated with workload certificates is exposed to the same stream and header attacks as public listeners, often with fewer limits configured. Apply the same limits on internal listeners and authenticate callers before expensive processing. See the mTLS Guide.

QUIC and HTTP/3 transport security

  • TLS 1.3 is built in: QUIC uses TLS 1.3 for its handshake and protects packets with keys derived from it. There is no unencrypted QUIC mode and no option to negotiate older TLS versions.
  • Anti-amplification: before a client address is validated, a QUIC server must not send more than three times the bytes it has received from that address, and clients must pad Initial datagrams to at least 1200 bytes (RFC 9000 Section 8). Monitor this in your QUIC stack if you run it yourself.
  • Retry and address validation: a server can answer with a Retry packet carrying a token, forcing the client to prove its address before the server commits state. RFC 9312 describes Retry as the functional analogue of TCP SYN cookies. Enable Retry under load; tokens must be unpredictable, integrity-protected and short-lived, and servers should limit token replay.
  • Connection IDs and migration: a QUIC connection survives a change of client IP address or port. Endpoints validate new paths, and intentional migration changes the connection ID so observers cannot link the flows. Rate limits keyed only on source IP can be weaker for QUIC than for TCP.
  • 0-RTT early data: early data can be captured and replayed. RFC 8470 lets servers reject early data, defer processing until the handshake completes, or answer 425 Too Early. Intermediaries that forward a request before their own client handshake completes must add Early-Data: 1. Allow 0-RTT only for requests that are safe to replay, and remember that some GET requests have side effects.
  • QPACK: HTTP/3 replaces HPACK with QPACK because QUIC does not guarantee in-order delivery. The decoding-cost concerns of HPACK carry over; bound the dynamic table and field section size.
  • CONNECT and malformed messages: RFC 9114 says intermediaries that are not acting as tunnels must not forward malformed requests, and proxies supporting CONNECT should restrict it to known ports or safe targets.

QUIC visibility and inspection blind spots

RFC 9312 (Informational, September 2022) is the IETF's manual for operators. Its key points for security teams: no information in the QUIC header is meant to be modified by the network; integrity protection makes any modification cause the packet to be discarded; packet numbers are protected and loss cannot be measured passively; and identifying QUIC by port or version is unreliable because QUIC also carries DNS over QUIC and SMB over QUIC, and new versions will appear. The Initial packets can be decrypted by anyone who knows the version's published salt, so the ClientHello and SNI are visible unless Encrypted Client Hello is used.

For an enterprise, the practical consequence is that a TLS-intercepting proxy, a secure web gateway in explicit or transparent TCP mode, or a firewall's decryption policy does not see HTTP/3 traffic unless the product specifically supports QUIC. Users then bypass URL filtering, DLP and malware scanning without doing anything deliberate, simply because their browser prefers HTTP/3.

OptionWhen it fitsTrade-offs
Block UDP 443 outbound (whole flows) and let clients fall back to TCPYou rely on TLS inspection, SWG or DLP for web traffic and your tools do not inspect QUICSlightly slower connections on lossy networks; must be done as flow blocking, not partial dropping, or fallback fails
Allow QUIC, inspect with a QUIC-aware gateway or endpoint agentYour SSE or endpoint agent supports HTTP/3 inspectionConfirm what is actually inspected; vendor support varies
Allow QUIC only to sanctioned destinationsVideo conferencing or SaaS where QUIC performance mattersDestination lists need maintenance; SNI-based rules depend on visible SNI
Disable HTTP/3 in managed browsers by policyManaged fleet, network blocking not possible everywhere (remote users)Only covers managed browsers, not other QUIC clients
Allow QUIC without inspectionGuest networks, or organisations without web inspectionRely on DNS filtering, endpoint controls and SNI visibility

RFC 9312 warns that dropping a random fraction of UDP packets lets many handshakes complete but causes heavy loss and prevents TCP fallback, so if you throttle or block QUIC, do it per flow. It also recommends a state timeout of at least two minutes for QUIC flows in stateful devices, which matters for firewalls and NAT that use short UDP timers. On the server side, publishing HTTP/3 also means your WAF, rate limits and bot controls must apply to the QUIC listener; check that the edge enforces the same policy on HTTP/3 as on HTTP/2. See the TLS Inspection Guide and the Secure Web Gateway and Web Filtering Guide.

Detection and measurement

Application logs are usually written when a request completes, so most HTTP/2 protocol abuse is invisible there. Log at the edge and at the connection level.

  • Per-connection counters: streams opened, streams reset by the client, reset-to-complete ratio, frames per second by type, connections closed with GOAWAY and the error code (ENHANCE_YOUR_CALM, PROTOCOL_ERROR, COMPRESSION_ERROR).
  • Incomplete requests: headers not completed within the timeout, 431 responses, and memory per connection. CERT/CC notes that CONTINUATION attacks may only be visible in raw HTTP/2 traffic.
  • Backend effects: requests dispatched to origin that were cancelled before a response, and origin CPU against edge request rate.
  • QUIC on the network: outbound UDP 443 volume by destination and by host, QUIC to destinations not on any sanctioned list, and the share of web traffic not seen by the SWG.
  • QUIC on your servers: Retry rate, handshake failures, and amplification limit hits.

Suggested metrics:

  1. Percentage of HTTP/2 and HTTP/3 implementations on a version patched for CVE-2023-44487 and the VU#421644 CVEs (target 100%).
  2. Percentage of listeners with explicit field section size, CONTINUATION and reset limits configured.
  3. Time to detect and close an abusive connection in a controlled test.
  4. Share of outbound web traffic (by bytes) that bypasses inspection because it uses QUIC.
  5. Edge-to-origin request amplification during load tests (requests reaching origin per accepted client stream).

Rolling out the controls

  1. Inventory: list every component that terminates HTTP/2 or HTTP/3: CDN, load balancers, reverse proxies, API gateways, ingress, service mesh, application runtimes. Note whether each is internet-facing.
  2. Patch: bring every component to a release fixed for CVE-2023-44487 and any applicable VU#421644 CVE. Track this with vulnerability management, not as a one-off. See the Load Balancer Security Guide.
  3. Set limits in observe mode: where the product supports logging before enforcement, enable reset counting and header limits with logging only for a week and review which legitimate clients would be affected.
  4. Enforce at the edge first: enable limits on the CDN or outermost proxy, then on internal hops. Keep the previous configuration versioned for rollback.
  5. Test: run an authorised load test against a staging endpoint using a reputable HTTP/2 load testing tool, and confirm the connection is closed and the origin is protected.
  6. Decide the QUIC policy: agree with the web security owner whether to block UDP 443, inspect it or allow it to named destinations. Pilot with one office or user group, watch helpdesk tickets, then extend.
  7. Review 0-RTT: confirm which endpoints accept early data and that non-idempotent routes return 425 or defer processing.

Framework mapping

FrameworkReferenceHow it applies
NIST SP 800-53 Rev. 5SC-5 Denial-of-service Protection; SC-7 Boundary Protection; SC-8 Transmission Confidentiality and Integrity; SI-2 Flaw Remediation; SI-4 System Monitoring; CM-6 Configuration SettingsStream and header limits, QUIC egress policy, patching HTTP/2 stacks, connection-level monitoring
NIST CSF 2.0PR.IR-01; DE.CM-01Protecting networks from unauthorised use, monitoring network services
CIS Controls v8.1Control 12 Network Infrastructure Management; Control 13 Network Monitoring and DefenseHardened network devices, traffic filtering and monitoring including UDP 443
ISO/IEC 27001:2022 Annex A8.20 Networks security; 8.21 Security of network services; 8.16 Monitoring activitiesNetwork service configuration and monitoring
MITRE ATT&CKT1499.002 Service Exhaustion Flood; T1498 Network Denial of ServiceRapid Reset and CONTINUATION are application-layer exhaustion
MITRE D3FENDD3-ITF Inbound Traffic Filtering; D3-NTA Network Traffic AnalysisEdge filtering and connection-level analysis

Common failure patterns

  • Patching the edge but not the inside: the CDN is fixed, but internal Envoy sidecars, Go services and API gateways still run vulnerable HTTP/2 code and are reachable from partner networks or compromised workloads.
  • Treating concurrency as the fix: lowering SETTINGS_MAX_CONCURRENT_STREAMS breaks clients and still allows Rapid Reset, because reset streams do not count against the limit.
  • No limits on headers: leaving SETTINGS_MAX_HEADER_LIST_SIZE and timeouts at defaults, which are unlimited or generous, so one connection can hold large amounts of memory.
  • Silent QUIC bypass: the SWG and DLP report healthy coverage while a large share of browser traffic uses HTTP/3 over UDP 443 and is never inspected.
  • Breaking fallback: a firewall or rate limiter drops some UDP packets rather than whole flows, so QUIC handshakes half-succeed, browsers do not fall back to TCP and users see intermittent failures.
  • 0-RTT on state-changing routes: early data enabled globally at the edge, so a replayed POST or a GET with side effects is processed twice.

Practitioner checklist

  • Inventory every HTTP/2 and HTTP/3 termination point, internal and external, with versions.
  • Confirm fixes for CVE-2023-44487 and the CERT/CC VU#421644 CVEs on every component.
  • Configure per-connection RST_STREAM accounting with GOAWAY and ENHANCE_YOUR_CALM above a threshold.
  • Set explicit field section limits, CONTINUATION limits and header read timeouts; return 431 on oversized headers.
  • Disable h2c upgrade, server push and unused protocol versions on public listeners.
  • Decide and document the QUIC egress policy; block whole flows if you block, and set QUIC state timeouts of at least two minutes.
  • Apply the same WAF, rate limit and bot rules to HTTP/3 listeners as to HTTP/2.
  • Limit 0-RTT to replay-safe requests and support Early-Data and 425 Too Early.
  • Log connection-level HTTP/2 counters and GOAWAY codes at the edge and alert on reset ratios.
  • Re-test with an authorised load test after every major proxy or runtime upgrade.

Standards and references

Related NHI Mgmt Group resources: DDoS Protection Guide · HTTP Request Smuggling Guide · TLS Inspection Guide · Web Application Firewall Guide · Encrypted Client Hello Guide

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.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 27 October 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org