How Safari Prevents WebRTC STUN IP Address Leaks

This article explains the specific security mechanisms the Safari web browser uses to prevent WebRTC STUN requests from leaking your local and public IP addresses. By obfuscating local network addresses with Multicast DNS (mDNS), gating network discovery behind explicit user permissions, restricting network interface enumeration, and respecting system proxies, Apple's WebKit engine ensures user privacy during peer-to-peer connections.

Understanding the WebRTC STUN Vulnerability

Web Real-Time Communication (WebRTC) allows browsers to establish direct peer-to-peer connections for video, audio, and data sharing. To do this, browsers use Session Traversal Utilities for NAT (STUN) servers to discover their public IP address and local network addresses (known as ICE candidates). Historically, websites could silently run JavaScript to trigger STUN requests, bypassing VPNs and proxies to reveal a user's true local and public IP addresses without their knowledge. Safari prevents this through four distinct layers of protection.

1. Multicast DNS (mDNS) Masks Local IP Addresses

To prevent websites from mapping a user's home or corporate network, Safari hides local IP addresses (such as 192.168.1.x or 10.0.0.x) using Multicast DNS.

When a website initiates a WebRTC connection in Safari, the browser does not generate an ICE candidate containing the raw local IP address. Instead, Safari generates a random, temporary Universally Unique Identifier (UUID) ending in .local (for example, f81d4fae-7dec-11d0-a765-00a0c91e6bf6.local). The browser provides this mDNS hostname to the web application. The actual local IP address is only resolved at the network level between devices on the same local network, making it completely invisible to the website's JavaScript and external servers.

2. Permission-Gated ICE Candidate Gathering

Safari ties the level of network information a website can access directly to user consent. A website cannot fully probe network paths until the user explicitly grants permission to use the device's camera or microphone.

If a website attempts to quietly run a WebRTC script in the background without requesting media permissions, Safari strictly limits the ICE candidate gathering process. In this unprivileged state, Safari blocks the revelation of host candidates (local IPs) entirely. It only allows the browser to gather server-reflexive candidates (public IPs) using the default network route, ensuring that background tracking scripts cannot abuse STUN requests to harvest detailed network configurations.

3. Restricting Network Interface Enumeration

A major cause of public IP leaks in other browsers is the enumeration of all available network interfaces. If a user is connected to a VPN, a standard WebRTC implementation might send STUN requests through the VPN interface, the Wi-Fi interface, and the Ethernet interface simultaneously to find the fastest route. This exposes the true public IP address assigned by the ISP alongside the VPN's IP address.

Safari prevents this by refusing to enumerate all network interfaces by default. Instead, Safari restricts WebRTC STUN requests to the system's "default route"—the exact same network path used for standard HTTP web traffic. If a user is connected to a properly configured VPN, the VPN becomes the default route. Safari will only send STUN requests through the VPN tunnel, ensuring the STUN server only sees the VPN's public IP address and never the user's real public IP.

4. iCloud Private Relay Integration

For users with iCloud Private Relay enabled, Safari adds an additional layer of protection against public IP leaks. While Private Relay primarily protects standard web browsing (HTTP/3 and DNS traffic), Safari is engineered to detect when a WebRTC STUN request is being made while Private Relay is active.

To prevent a website from using WebRTC as a loophole to bypass Private Relay and discover the user's real public IP, Safari routes the STUN traffic through Apple’s relay architecture or masks the reflexive IP candidates. This ensures that the public IP address returned by the STUN server matches the anonymized IP address provided by Private Relay, maintaining consistent privacy protection.