What should teams do when vendors claim HTTP/2 support but still use HTTP/1.1 internally?

Teams should ask for the full request path, not just the edge protocol banner. If internal HTTP/1.1 still exists, request smuggling remains possible even when the front end advertises modern transport. The right response is to require architectural clarification, document the downgrade point, and prioritise removal of the legacy hop where feasible.

Why This Matters for Security Teams

HTTP/2 at the edge does not automatically mean the application path is safe end to end. When a vendor terminates modern traffic at the perimeter but forwards requests over HTTP/1.1 internally, the security question shifts from protocol branding to trust boundaries and parsing consistency. That matters because request smuggling depends on disagreement between components, and a single downgrade hop can reintroduce that risk even when the public-facing service looks current. The NIST Cybersecurity Framework 2.0 is useful here because it pushes teams to understand assets, dependencies, and protective controls rather than relying on marketing claims.

Practitioners often get misled by a clean scanner result or a vendor statement that only describes the ingress layer. That is not enough. Security teams need to know where framing changes, where headers are normalised, and whether the internal hop preserves request integrity under malformed or ambiguous inputs. In practice, many security teams encounter request smuggling only after an incident, rather than through intentional architecture review.

How It Works in Practice

The operational issue is usually a chain of proxies, gateways, or load balancers that do not treat a request the same way. HTTP/2 uses a different framing model from HTTP/1.1, so if the front end accepts one format and the back end interprets another, an attacker may create ambiguity in how request boundaries are parsed. The real control question is not “Does the vendor support HTTP/2?” but “Is there any downgrade point where parsing assumptions change?” That is where review should start.

Security and platform teams should ask for the full request path, including CDN, WAF, reverse proxy, application gateway, service mesh, and origin server. They should also ask whether the vendor has tested for request smuggling classes such as header confusion, transfer encoding inconsistencies, and proxy desynchronisation using authorised testing methods described by the OWASP HTTP Request Smuggling guidance.

• Confirm where HTTP/2 terminates and where any HTTP/1.1 hop begins.
• Verify whether headers are rewritten, normalised, or stripped between layers.
• Ask for evidence of parser alignment testing across all intermediaries.
• Document any protocol downgrade point as a security dependency.
• Prefer removal of the legacy hop, or enforce a design that preserves request framing consistently.

From a governance perspective, the most useful evidence is an architecture diagram plus a short control statement that identifies the downgrade boundary, the owner of that component, and the compensating controls in place. Where application teams also operate identity-aware gateways, token propagation and session handling should be checked as part of the same path review, because request confusion often creates secondary access-control failures. These controls tend to break down in multi-tenant edge stacks with mixed proxy generations because each component may be standards-compliant in isolation while still disagreeing on message boundaries.

Common Variations and Edge Cases

Tighter protocol enforcement often increases integration cost and can expose legacy dependencies, requiring organisations to balance resilience against delivery friction. That tradeoff is real, especially where the vendor controls only the edge service and not the upstream application estate. Best practice is evolving, but current guidance suggests that “HTTP/2 supported” should be treated as an incomplete statement unless the entire request path is confirmed.

There are a few common edge cases. Some providers advertise HTTP/2 externally while still translating to HTTP/1.1 internally for caching, routing, or application compatibility. Others use mixed infrastructure where one zone is modernised and another remains legacy. In those environments, a security team should ask whether the downgrade is deliberate, whether it is temporary, and whether the vendor has a roadmap to eliminate it. If the answer is no, the risk should be documented as a residual architectural exposure, not just a scanner finding.

For regulated environments, this issue may also affect broader assurance work under MITRE ATT&CK style threat modelling because request smuggling often becomes a pivot for cache poisoning, authentication bypass, or backend request manipulation. The practical test is simple: if the vendor cannot explain how each hop parses the same request, the control picture is incomplete.

Related resources from NHI Mgmt Group

• How do security teams know if Kerberos RC4 is still in use?
• How should security teams harden domain controllers that still need legacy authentication support?
• How should security teams use existing identity tools to support audit readiness?
• How should teams use file integrity monitoring to support identity governance?