HPACK

How HPACK Works

HPACK is the header-compression layer for HTTP/2. Its job is to reduce repeated metadata overhead by encoding common header fields efficiently, which improves throughput and lowers bandwidth use on header-heavy connections.

That efficiency comes from reuse. Rather than sending the same header material in full on every request, HPACK can refer to previously seen values and reconstruct them during decoding. This makes HTTP/2 more efficient, but it also means the decoder must safely manage tables, references, and expansion behavior.

Why HPACK Matters in HTTP/2

HPACK is not just a transport detail. It affects how much work a server or intermediary must do to process each request, how much memory gets allocated during decompression, and how predictable request handling remains under load. In high-throughput environments, a compression layer can become a scaling boundary if it is not tightly constrained.

The main security relevance is that compressed inputs can be smaller on the wire than they become in memory. If the implementation accepts encoded data that expands into very large decoded structures, HPACK can create disproportionate resource consumption and parser pressure even when the incoming traffic looks modest.

Where HPACK Becomes a Security Concern

HPACK is dangerous when decoding assumptions are looser than attacker-controlled input. A server that accepts compressed references without enforcing strict decoded-size ceilings, table bounds, or allocation safeguards can be pushed into excessive memory use, CPU churn, or request processing instability.

This is especially important in shared services, reverse proxies, and front-end gateways where one weak decoder can affect many downstream applications. Header compression is a normal protocol feature, but like any stateful parser, it becomes an attack surface when input expansion is not carefully bounded.

How to Evaluate Exposure and Reduce Risk

Organisations should identify every HTTP/2 endpoint, proxy, gateway, and library that handles HPACK decoding, then verify whether the implementation has hard limits on decoded header size, dynamic table growth, and per-connection resource use. Vendor advisories and protocol implementation notes are the authoritative place to confirm exact behavior.

When a fix cannot be applied immediately, compensating controls usually mean reducing exposure to untrusted traffic, constraining request rates, tightening reverse-proxy limits, and monitoring for abnormal header-compression behavior. Good NIST SP 800-53 Rev 5 Security and Privacy Controls practice also supports logging, resource governance, and robust configuration management around protocol handlers.

Detection and Post-Exposure Review

After a suspected issue, review whether the service experienced memory spikes, request failures, connection resets, or unusual header sizes that could indicate decompression pressure. Detection is usually behavioral rather than signature-based, because the danger lies in how the implementation reacts to crafted input.

For broader hardening, NIST Cybersecurity Framework 2.0 provides a useful posture model for identifying assets, detecting anomalous behavior, and recovering from service degradation, while CIS Benchmarks help reduce the chance that adjacent platform misconfiguration amplifies protocol-layer abuse.

Risk and Threat Considerations

HPACK risk is less about header compression itself and more about what happens when compressed input expands into large in-memory structures faster than the implementation can safely govern it. That creates a resource-exhaustion path that can destabilise front ends, proxies, and shared HTTP/2 infrastructure.

Failure mechanism: An attacker sends crafted compressed headers that trigger disproportionate expansion, excessive table growth, or repeated allocation work, exhausting memory or CPU in the decoder.

Impact: The service may slow down, drop connections, return errors, or become unavailable, and in multi-tenant or shared gateway designs the blast radius can extend beyond one application.

Practitioner Guidance

Why practitioners should care: HPACK should be treated as a protocol-processing risk surface, not just a performance optimization. Security teams and platform owners need to know which components decode it, what limits they enforce, and whether those limits are consistent across libraries and ingress tiers.

What to watch for: Look for divergent behavior between load balancers, proxies, and application servers, especially where one layer enforces limits but another silently expands inputs further downstream. That mismatch is where decompression abuse tends to become operationally visible.

Practitioner takeaway: If HTTP/2 is enabled, validate HPACK bounds explicitly in the stack rather than assuming the library defaults are safe.

Related resources from NHI Mgmt Group

• HPACK Compression Bomb