How HTTP/3 and QUIC challenge established web security assumptions

Modern web security is built on a set of long-standing assumptions: HTTPS runs over TCP, uses port 443, and can therefore be inspected, classified, and filtered accordingly. If non-standard ports are used, those are clearly identified in the URL.

As HTTP/3 and QUIC gain adoption, these assumptions no longer always hold true.

The following example demonstrates how the same URL can lead to completely different content being delivered - without any visible indication to the user.

The same URL, different results

When accessing https://sampleattackdomain.com two browsers display very different pages:

• Chrome shows a benign informational website.
• Safari displays an alternative version that could contain highly malicious content.

From the user’s perspective, both accesses appear identical:

• the URL is unchanged
• no redirect occurs
• no non-standard port is visible

Yet the delivered content differs fundamentally.

A closer look at the network traffic

Network traces explain what is happening behind the scenes:

• Chrome connects via HTTP/1.1 or HTTP/2 over TCP port 443, following the traditional HTTPS model
• Safari establishes an HTTP/3 connection over QUIC using UDP port 3479 - a port range commonly used for collaboration and real-time communication services

Both browsers access the same hostname, but they use entirely different transport protocols and ports.

Why this matters from a security perspective

This behavior has several important implications:

First, the URL alone does not reveal which protocol or port is being used.
Users have no indication that different delivery paths are involved.

Second, UDP port ranges such as 3478–3481 are frequently permitted in enterprise environments to support applications like Microsoft Teams, Zoom, or WebRTC. These rules are often broader than intended. Hence, some standard HTTP/3 blocking rules may fail!

Third, many secure web gateways and inspection systems still lack full support for HTTP/3 and QUIC. Traffic that is neither clearly blocked nor properly inspected may pass without content analysis.

Finally, automated security scanners and reputation systems often behave like Chrome in this example. They connect via TCP port 443, observe only the benign content, and therefore classify the domain as trusted - while alternative content remains undiscovered.

Why does Safari select HTTP/3?

The deciding factor is DNS.

Safari issues a DNS HTTPS (Type 65) query when resolving the hostname.
The DNS response explicitly advertises:

• HTTP/3 support (alpn=h3)
• a non-standard port (3479)
• the same host name

Safari follows this information and establishes a QUIC connection accordingly.

Chrome, by contrast, did not use this DNS HTTPS information in the current version we tested and therefore connected to the traditional HTTP/2 or HTTP/1.1 service on TCP port 443.

Is this a browser-specific issue?

No, this is not a Safari-only problem!

The scenario can easily be reversed.
If an HTTP/2 server advertises HTTP/3 via an Alt-Svc header, Chrome will follow that advertisement while Safari may not.

The underlying issue is not the browser, but the fact that different protocol discovery mechanisms exist and are not always considered by security controls.

If you are interested in more details, read our article "How do Browser and Website Negotiate Which HTTP Version is Used?"

Implications for enterprise environments

This example illustrates a broader challenge:

• DNS can now influence transport protocol and port selection.
• HTTP/3 can operate on arbitrary UDP ports.
• Many security architectures remain optimized for TCP-based HTTPS on port 443.

As a result, visibility gaps may emerge - not because of misconfiguration, but because security tooling has not yet fully adapted to modern web transport mechanisms.

Practical considerations for mitigation

Organizations should consider several defensive measures:

• UDP traffic should be treated as potential web traffic, not merely as “media traffic”.
• Broad UDP allowances should be restricted to known destinations and services wherever possible.
• DNS HTTPS records (Type 65) should be included in security analysis and policy decisions.
• HTTP/3 should not simply be ignored or aimed to be generically blocked; both approaches create operational and security challenges.

Ultimately, web security solutions must be able to understand and process HTTP/3 and QUIC in the same depth as traditional HTTPS.

To make these behaviors easier to validate in real environments, we provide the SSE Testcenter. It includes controlled endpoints for testing DNS HTTPS discovery, Alt-Svc based HTTP/3 upgrades, HTTP/3 availability on non-standard UDP ports, and gateway behavior when multiple protocol paths are available for the same hostname.

Conclusion

HTTP/3 is no longer an experimental protocol.
It is supported by all major modern browsers, and a wide range of web servers support it too. This creates opportunities for attackers to hide alternative delivery paths from scanners, reputation systems, or security controls that still focus primarily on TCP-based HTTPS.

Security strategies that focus exclusively on TCP port 443, or merely aim to block HTTP/3 traffic, may lose visibility into significant parts of modern web traffic and risk creating bypass opportunities. Adapting security architectures to these changes is essential to maintain consistent protection.