HTTP/2 in 5G Networks: The New Language of Telecom — and Its Security Risks

Introduction: Telecom Meets IT Protocols

5G didn’t just change the radio—it fundamentally redefined the core network architecture. Instead of relying on telecom-specific protocols like Diameter or SS7, the 5G Core is built on an IT-native foundation: cloud, microservices, containers, and APIs.

At the heart of this shift lies HTTP/2, the protocol chosen for Service-Based Interfaces (SBI) in the 5G Service-Based Architecture (SBA). For the first time, the mobile core speaks the same language as web applications and enterprise APIs.

This makes 5G more flexible, scalable, and developer-friendly—but also exposes telecom networks to new classes of attacks that operators never had to worry about before.

Why HTTP/2 in 5G?

The decision to adopt HTTP/2 in 5G was deliberate. Compared to Diameter and SS7, HTTP/2 provides:

• Multiplexing: Multiple streams over a single TCP connection, improving efficiency.
• Header Compression (HPACK): Reduced signaling overhead, critical in dense 5G traffic.
• Server Push & Stream Prioritization: Faster, more responsive communication between Network Functions (NFs).
• Compatibility with IT Ecosystem: Easy integration with cloud-native infrastructures (Kubernetes, Docker, service meshes).
• API-Driven Communication: Enables network slicing, MEC (Multi-access Edge Computing), and new 5G services via open APIs.

In short: HTTP/2 is the enabler of 5G’s “network-as-a-service” vision.

Where HTTP/2 Lives in the 5G Core

HTTP/2 is used for Service-Based Interfaces (SBI) between Network Functions, replacing the point-to-point signaling of older generations. Some key players include:

• AMF (Access & Mobility Management Function) – communicates with the SMF, UDM, AUSF via HTTP/2 APIs.
• SMF (Session Management Function) – establishes data sessions, again over HTTP/2.
• NRF (Network Repository Function) – service registry for all NFs, API-driven.
• PCF (Policy Control Function) – applies QoS and charging rules via APIs.

All of these talk to each other via HTTP/2 REST-style messages rather than proprietary telecom protocols.

Security Challenges of HTTP/2 in 5G

While HTTP/2 enables innovation, it also introduces a massive shift in the threat landscape. Unlike SS7 or Diameter—which had their own flaws—HTTP/2 brings telecom into the world of web and API attacks.

Here are the most pressing security issues:

1. API Vulnerabilities

• Poor authentication, broken access controls, and unvalidated inputs expose Network Functions.
• Attackers can exploit weak APIs to disrupt sessions, extract subscriber data, or manipulate network slices.

2. HTTP/2-Specific Exploits

• HPACK Bombs (Header Compression Attacks): Can cause CPU/memory exhaustion.
• Request Flooding & Stream Abuse: Multiplexing can be abused for DoS.
• Malformed Frames: Exploiting differences in how implementations parse frames.

3. Interconnection Risks

• In roaming scenarios, HTTP/2 messages flow across inter-operator connections. If not filtered and authenticated, attackers can abuse them just like SS7/Diameter signaling in earlier generations.

4. TLS Misconfiguration

• While HTTP/2 mandates TLS for most deployments, weak cipher suites, expired certificates, or poor key management can leave NFs exposed.

5. Expanded Attack Surface

• With 5G’s cloud-native model, attackers can now target not just HTTP/2 traffic but also the infrastructure hosting it—containers, service meshes, Kubernetes clusters.

Real-World Threats: From Telecom to IT and Back

What’s dangerous is not just HTTP/2 itself, but the convergence of telecom and IT threats. Telecom operators now have to defend against:

• Classic signaling attacks (session hijacking, impersonation).
• Web-style exploits (API abuse, fuzzing, injection, DoS).
• Cloud-native threats (supply chain attacks, container escapes).

Attackers no longer need deep SS7 knowledge—web hackers can now directly target telecom APIs.

Securing HTTP/2 in 5G Networks

To make HTTP/2 in 5G secure, operators need a hybrid defense strategy blending telecom signaling security with modern IT practices:

1. API Security Gateways
   • Enforce authentication, authorization, and input validation.
   • Rate-limit and monitor NF-to-NF API calls.
2. HTTP/2-Aware Firewalls
   • Detect HPACK bombs, malformed frames, and abnormal multiplexing.
   • Block request floods before they impact Network Functions.
3. TLS Best Practices
   • Use strong cipher suites, short-lived certificates, and automated certificate rotation.
   • Enforce mutual TLS (mTLS) between NFs.
4. Zero-Trust Interconnection
   • Apply strict controls on HTTP/2 messages from roaming partners.
   • Filter and validate external SBI traffic.
5. Continuous Monitoring & Threat Intelligence
   • Detect anomalies in HTTP/2 traffic patterns.
   • Correlate API activity with subscriber sessions to spot fraud.
6. Cloud-Native Security Integration
   • Harden Kubernetes, container registries, and service meshes.
   • Apply runtime security to detect lateral movement across NF instances.

Conclusion

HTTP/2 is the backbone of 5G’s Service-Based Architecture, enabling flexible, API-driven mobile networks. But with this evolution comes a new breed of risks.

What used to be a telecom-only playground of SS7 and Diameter is now open to web exploit kits, API hackers, and cloud-native attackers. Operators must treat HTTP/2 not as “just another protocol,” but as a critical attack vector in the 5G core.

Securing HTTP/2 is about securing the entire 5G ecosystem—from APIs to interconnection links to the cloud-native infrastructure itself. Fail to do so, and attackers won’t just compromise a session—they’ll compromise the very trust in mobile connectivity.

🔐 Looking for the full picture? Explore the Ultimate Guide to Mobile Network Security — your complete resource on telecom security, from architecture to audits.