Should organisations remove HTTP/2 or keep it and harden the gateway?

If the listener is public and the business does not require HTTP/2 there, removal is the fastest risk reduction. If HTTP/2 must stay, terminate it before Envoy, cap resource use tightly, and patch immediately. The right answer depends on exposure, but the security goal is the same: stop a single connection from becoming a denial of service.

When does removing HTTP/2 beat hardening the gateway?

Removal is the safer default when the public listener does not need HTTP/2 and you want to eliminate a class of multiplexing and connection-management risk quickly. If the protocol is only adding compatibility rather than business value, removing it shrinks the attack surface and reduces the chance that one expensive connection can monopolise the edge.

That decision is less about taste than about exposure. A public-facing gateway that accepts arbitrary client traffic is a different risk profile from an internal hop or a controlled partner interface, and the more exposed the listener is, the more attractive it becomes to keep the protocol set as small as possible.

If HTTP/2 stays, what has to be true about the gateway?

Keeping HTTP/2 can be reasonable when the service benefits from it, but it only stays safe if the gateway is treated as a constrained resource boundary, not a transparent pass-through. Terminate HTTP/2 before Envoy where possible, enforce tight limits on concurrent streams and connection counts, and make sure overload degrades cleanly instead of cascading into broader service failure.

That hardening posture matters because the protocol’s efficiency features can also concentrate load. If the edge accepts too much concurrency, too many long-lived connections, or too much work per request, an attacker does not need to break authentication or exploit a code flaw to create meaningful denial of service pressure.

What should teams verify before deciding?

The first check is simple: do you actually need HTTP/2 on that listener, or are you keeping it because it is enabled by default? The second is operational: can the gateway survive a surge in expensive connections without starving other traffic, saturating worker pools, or creating a retry storm downstream?

Teams should also confirm that patching is current, because protocol-level weakness and implementation flaws are often fixed faster than architectural changes can be deployed. If the listener must remain public, the practical decision is not just whether HTTP/2 is present, but whether the surrounding controls make it bounded, observable, and easy to take out of service if conditions change.

Risk and Threat Considerations

HTTP/2 on a public listener increases the likelihood that an attacker can turn one connection into disproportionate resource consumption. The main risk is not confidentiality loss, but service degradation, especially where the edge or proxy layer does more work per connection than the application team expects.

Failure mechanism: Multiplexed streams, long-lived sessions, or poorly tuned connection limits can let a small amount of attacker traffic consume worker capacity, memory, or upstream sockets faster than the platform can recover.

Impact: The likely outcome is denial of service, partial outage, or noisy degradation that masks a broader incident and forces emergency traffic shedding or protocol rollback.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	Hardening the gateway and reducing exposed protocol surface are secure configuration concerns.
Recommendation — Disable unnecessary protocols and enforce hardened baseline settings on the public listener.
NIST CSF 2.0	PR.PS-01 — Platform Security	Limiting protocol exposure and hardening the edge are platform security measures for public services.
Recommendation — Reduce exposed services and harden the platform that terminates external traffic.
NIST SP 800-53 Rev 5	SC-5 — Denial of Service Protection	The question centers on preventing a single connection or client from consuming excessive service resources.
Recommendation — Tune service and network controls to limit denial-of-service impact at the boundary.
OWASP ASVS	V12 — Secure Communication	Protocol choice and termination behavior affect secure transport handling and gateway exposure.
Recommendation — Require secure transport handling and constrain protocol behavior at the boundary.
ISO/IEC 27001:2022	A.8.20 — Network security	Public listener exposure and gateway hardening are network security control issues.
Recommendation — Harden network-facing components and minimise unnecessary exposure.

Practitioner Guidance

What to prioritise: If the listener is public and HTTP/2 is not required for a business reason, remove it first. That gives the fastest reduction in exposure, and it is usually easier to justify than chasing every possible tuning combination.

What to verify: If HTTP/2 must remain, verify that the gateway, not the application tier, absorbs the abuse potential. Set explicit ceilings on connection lifetime, concurrent streams, request buffering, and total resource spend per client so overload is visible and contained at the edge.

Decision rule: If you cannot show that the gateway fails closed under stress, treat HTTP/2 as a material availability risk until you can. If you can, keep it only where it provides clear operational value.

Practitioner takeaway: The safe choice is the one that prevents a single client connection from becoming a shared-service outage, whether that means removing HTTP/2 or constraining it hard enough that it cannot dominate the edge.