HTTP/2 Security
Guide to HTTP/2 security covering binary framing, HPACK compression attacks, rapid reset vulnerability, stream multiplexing risks, and mitigation strategies.
Continue your mission
Guide to HTTP/2 security covering binary framing, HPACK compression attacks, rapid reset vulnerability, stream multiplexing risks, and mitigation strategies.
# HTTP/2 Security
HTTP/2 is the second major version of the Hypertext Transfer Protocol, standardized in RFC 7540 in 2015, designed to address the performance limitations of HTTP/1.1 while maintaining compatibility with existing web applications. Unlike its predecessor, HTTP/2 fundamentally changes how web traffic moves between clients and servers through binary framing, stream multiplexing, and header compression.
The protocol emerged from Google's SPDY experiment, which demonstrated that web performance could improve dramatically without changing how applications work. Major browsers and web servers adopted HTTP/2 rapidly: by 2024, over 60% of all websites support HTTP/2, making it the dominant protocol for modern web applications.
HTTP/2 exists to solve the connection multiplier problem that plagued HTTP/1.1. Traditional web pages require dozens of separate resources (images, stylesheets, scripts, fonts), and HTTP/1.1 handles each request serially or requires multiple TCP connections. This creates latency bottlenecks and connection overhead that compound as web applications grow more complex. HTTP/2 multiplexes all requests over a single connection, eliminating the performance penalties that drove developers to adopt workarounds like domain sharding, resource concatenation, and image sprites.
While HTTP/2 delivers substantial performance improvements, its complexity introduces attack surfaces that did not exist in HTTP/1.1. The binary framing layer, header compression algorithms, and stream multiplexing create new vectors for resource exhaustion, cache poisoning, and denial of service attacks. Organizations adopting HTTP/2 must understand these security implications, particularly because the performance benefits make rollback to HTTP/1.1 operationally unacceptable for most applications.
HTTP/2 replaces HTTP/1.1's text-based message format with a binary framing layer that divides communication into discrete frames. Each frame belongs to a specific stream, and multiple streams can be active simultaneously over a single TCP connection. This multiplexing eliminates head-of-line blocking that occurs when HTTP/1.1 requests must wait for preceding requests to complete.
The binary framing layer operates through several frame types. DATA frames carry the actual payload content. HEADERS frames contain request and response headers. PRIORITY frames control stream precedence. RST_STREAM frames terminate streams immediately. SETTINGS frames configure connection parameters. WINDOW_UPDATE frames manage flow control. Each frame includes a stream identifier that allows the recipient to route it correctly within the multiplexed connection.
Stream management introduces complexity that creates security implications. Clients can initiate thousands of concurrent streams over a single connection, each consuming server memory and processing resources. Stream states (idle, reserved, open, half-closed, closed) must be tracked individually. Streams can be assigned priorities and dependencies, creating a tree structure that servers must maintain and respect when allocating resources. A single malformed or malicious stream can affect the entire connection.
HPACK header compression reduces bandwidth consumption by maintaining a dynamic table of previously transmitted header names and values. When a client sends "User-Agent: Mozilla/5.0", HPACK might compress this to a single byte reference to table entry 58. The dynamic table grows throughout the connection lifetime as new headers are encountered. Both client and server maintain synchronized copies of this table, updating them identically as new headers arrive.
The compression mechanism creates a memory amplification attack vector. A malicious client can craft headers that compress efficiently during transmission but expand dramatically when processed. A 1KB compressed header might expand to several megabytes in server memory when decompressed and stored in the dynamic table. This HPACK bombing attack can exhaust server memory without triggering traditional rate limiting mechanisms that monitor raw bandwidth consumption.
Server push allows servers to proactively send resources to clients before they are requested. When a client requests an HTML page, the server might push the associated CSS and JavaScript files immediately rather than waiting for subsequent requests. The server sends a PUSH_PROMISE frame indicating its intent to push a resource, followed by the actual response. Clients can reject pushed resources with RST_STREAM frames if they already have the resource cached.
Flow control prevents fast senders from overwhelming slow receivers. HTTP/2 implements flow control at both the connection level and individual stream level using a credit-based system. Receivers advertise their buffer capacity through WINDOW_UPDATE frames. Senders must not transmit more data than the receiver has advertised space to handle. This prevents a single fast stream from consuming all available buffer space and starving other streams.
TLS integration differs significantly from HTTP/1.1 implementations. While HTTP/2 does not technically require encryption, all major browsers refuse to use HTTP/2 over unencrypted connections. This effectively mandates HTTPS for HTTP/2 adoption. The TLS handshake includes Application-Layer Protocol Negotiation (ALPN) extension negotiation, where client and server agree to use HTTP/2. The TLS connection then carries the binary-framed HTTP/2 traffic.
Stream multiplexing creates subtle interaction effects with TLS encryption. Because multiple streams share a single encrypted tunnel, timing attacks against one stream might reveal information about concurrent streams. The ordering of multiplexed frames can leak information about server processing priorities or application logic. Organizations must consider these cross-stream information disclosure risks when designing applications that handle sensitive data across multiple concurrent requests.
HTTP/2's complexity fundamentally changes the web application attack surface. Traditional HTTP/1.1 security controls, designed around discrete request-response pairs over separate connections, become inadequate against attacks that exploit stream multiplexing, header compression, and connection reuse. The performance benefits that drive HTTP/2 adoption also make these vulnerabilities attractive to attackers seeking maximum impact with minimal effort.
The Rapid Reset attack (CVE-2023-44487) demonstrates HTTP/2's potential for massive scale disruption. Attackers create streams and immediately cancel them with RST_STREAM frames, forcing servers to process stream creation overhead without delivering any useful work. A single attacker can generate thousands of stream creation and cancellation cycles per second, consuming server CPU and memory resources while staying below traditional bandwidth-based rate limits. This attack affected major platforms including Google, Amazon, and Cloudflare simultaneously, requiring coordinated industry response and emergency patches across dozens of HTTP/2 implementations.
Stream multiplexing amplifies resource consumption attacks beyond what HTTP/1.1 made possible. An attacker opening 100 concurrent streams over a single TCP connection consumes similar server resources to 100 separate HTTP/1.1 connections, but appears as a single connection to many monitoring systems. Traditional connection-based rate limiting becomes ineffective. Per-IP connection limits that prevent HTTP/1.1 abuse may allow 10 connections, each carrying 1000 multiplexed streams, effectively bypassing the intended protection.
Server push introduces forced cache poisoning vectors. Malicious servers or compromised Content Delivery Networks can push resources that the client did not request and may not validate properly. If an attacker pushes a malicious JavaScript file for "https://trusted-site.com/app.js", browsers might cache this resource and serve it when the user later visits the legitimate site. The pushed resource bypasses the normal request flow where browsers validate the source and apply appropriate security policies.
HPACK compression creates memory exhaustion attacks that are difficult to detect and prevent. Unlike traditional denial of service attacks that consume bandwidth or CPU cycles, HPACK bombing targets memory allocation through seemingly normal HTTP requests. A modest number of malicious requests can consume gigabytes of server memory. The attack traffic compresses well, making it difficult to distinguish from legitimate optimized web applications that also benefit from header compression.
Business impact extends beyond technical vulnerabilities. Organizations that deploy HTTP/2 without understanding its security implications face availability risks that can affect revenue and customer trust. E-commerce platforms experiencing Rapid Reset attacks may become unresponsive during peak shopping periods. Financial services applications targeted by HPACK bombing may exhaust memory and crash during market trading sessions. The performance benefits that justify HTTP/2 adoption become liabilities when security controls fail to account for the protocol's complexity.
Misconceptions about HTTP/2 security often center on the assumption that mandatory TLS encryption solves the protocol's security challenges. While HTTPS does protect data in transit and prevents basic man-in-the-middle attacks, it does nothing to address resource exhaustion, cache poisoning, or protocol-level abuse. Organizations cannot rely on encryption alone to secure HTTP/2 deployments.
HTTP/2 security spans both the Vulnerable Systems Detection (VSD) and Systems Protection Hardening (SPH) domains within CDA's Problem Domain Map. VSD owns the identification of HTTP/2 implementations vulnerable to known attacks like Rapid Reset, HPACK bombing, and stream exhaustion. SPH owns the hardening configurations that limit HTTP/2 attack surfaces: stream concurrency limits, header compression boundaries, server push policies, and flow control parameters.
CDA's approach to HTTP/2 security follows the Continuous Surface Reduction methodology: every HTTP/2 feature enabled is an attack surface that must be justified, monitored, and potentially eliminated. Unlike conventional security approaches that focus on detecting and blocking malicious HTTP/2 traffic, CSR emphasizes reducing the protocol's exposed functionality to the minimum required for business operations.
During C-BUILD missions, CDA operators assess HTTP/2 configurations systematically. They verify that servers implement per-stream resource limits to prevent memory exhaustion through excessive concurrent streams. They check for HPACK compression limits that prevent memory amplification attacks. They validate that stream reset rate limiting prevents Rapid Reset exploitation. They confirm that server push is disabled unless specifically required and properly secured.
CDA differs from conventional HTTP/2 security thinking in several important ways. Traditional approaches treat HTTP/2 features as inherently beneficial and focus on securing them through monitoring and access controls. CDA treats each HTTP/2 feature as a potential attack vector and requires explicit justification for its enablement. Server push, for example, is typically enabled by default in HTTP/2 implementations because it can improve performance. CDA disables server push unless the organization can demonstrate specific business value and implement appropriate security controls.
The CSR methodology applies directly to HTTP/2 multiplexing limits. Most HTTP/2 implementations allow hundreds or thousands of concurrent streams per connection to maximize performance benefits. CDA reduces stream concurrency to the minimum required for application functionality. A typical web application might require 10-20 concurrent streams for optimal page loading. Allowing 1000 concurrent streams exposes 980 streams worth of unnecessary attack surface.
CDA's approach extends to HTTP/2 header processing. While HPACK compression provides legitimate bandwidth benefits, CDA implements strict limits on compressed header size, decompressed header size, and dynamic table memory consumption. These limits prevent HPACK bombing while preserving the performance benefits that justify HTTP/2 adoption. Organizations that implement unlimited header processing expose themselves to memory exhaustion attacks for marginal compression improvements.
Cross-domain considerations within the PDM become critical for HTTP/2 deployments. VSD findings about HTTP/2 vulnerabilities must integrate with SPH hardening efforts and Network Security Architecture (NSA) traffic analysis. An HTTP/2 server vulnerable to Rapid Reset attacks requires immediate VSD remediation, SPH configuration hardening, and NSA monitoring to detect exploitation attempts. The multiplexed nature of HTTP/2 traffic complicates NSA analysis because traditional per-connection monitoring becomes insufficient for understanding application-layer attack patterns.
• HTTP/2's binary framing and stream multiplexing create new attack surfaces that traditional HTTP/1.1 security controls cannot address, requiring protocol-specific protections against resource exhaustion and memory amplification attacks.
• Mandatory HTTPS in HTTP/2 browser implementations improves data protection but does not prevent protocol-level abuse like Rapid Reset attacks, HPACK bombing, or malicious server push exploitation.
• Stream concurrency limits, header compression boundaries, and server push restrictions are essential security controls that must be implemented alongside HTTP/2 deployment to prevent resource exhaustion.
• CDA's Continuous Surface Reduction approach treats each HTTP/2 feature as an attack vector requiring explicit justification, contrasting with conventional approaches that assume protocol features are inherently beneficial.
• Organizations must implement HTTP/2-specific monitoring and rate limiting because traditional connection-based controls become inadequate when thousands of streams multiplex over single TCP connections.
• TLS Configuration Management • Web Application Security Architecture • Content Delivery Network Security • Application Layer DDoS Protection • Network Protocol Hardening
• Belshe, M., Peon, R., & Thomson, M. (2015). Hypertext Transfer Protocol Version 2 (HTTP/2). RFC 7540. Internet Engineering Task Force. • CVE-2023-44487: HTTP/2 Rapid Reset Attack. (2023). Common Vulnerabilities and Exposures. MITRE Corporation. • National Institute of Standards and Technology. (2023). SP 800-95: Guide to Secure Web Services. NIST Special Publication. • Thomson, M. & Reschke, J. (2018). RFC 8441: Bootstrapping WebSockets with HTTP/2. Internet Engineering Task Force.
CDA Theater missions that address topics covered in this article.
Cryptographic technique that encrypts data while preserving its original format and length, enabling protection without breaking legacy system compatibility.
Explanation of Certificate Transparency framework, covering log servers, Signed Certificate Timestamps, monitoring capabilities, and detection of fraudulent certificates.
Centralized tracking of organizational risks including likelihood, impact, ownership, and treatment plans for structured risk management.
Written by CDA Editorial
Found an issue? Help improve this article.