WebRTC Security: Encryption, SRTP, and DTLS Explained

WebRTC security rests on two mandatory protocols, DTLS and SRTP, working together to encrypt every connection by default. That default encryption answers the basic question of whether WebRTC is secure, covered in more depth in our companion guide on whether WebRTC is encrypted. This guide goes further, into how DTLS and SRTP actually work at the protocol level, and into the security areas WebRTC's specification deliberately leaves for an application to handle itself.

This guide covers the DTLS handshake mechanics, how SRTP derives and applies its encryption keys, WebRTC's browser-level permission model, IP address exposure through ICE negotiation, signaling channel security, and the common misconfigurations that undermine WebRTC security in practice.

What Does WebRTC Security Actually Cover?

WebRTC security covers mandatory transport encryption through DTLS and SRTP, browser-level permission enforcement for camera and microphone access, and connection setup through ICE, while explicitly leaving signaling channel security and TURN credential management to the application implementing WebRTC.

WebRTC security is not a single guarantee. It is a combination of protocol-level requirements the specification mandates and a set of areas the specification deliberately leaves for the implementing application to handle.

What WebRTC handles by specification: mandatory DTLS-SRTP encryption for every media and data channel connection, and a browser-enforced permission model requiring explicit user consent before any application can access a camera or microphone.

What WebRTC leaves to the application: securing the signaling channel used to set up a connection, managing TURN server credentials safely, and handling the IP address information that ICE negotiation can expose as part of establishing a connection.

Is Your WebRTC Signaling Channel Truly Hardened?

Schedule a Security Audit

DTLS in WebRTC: How the Handshake Actually Works

The DTLS handshake in WebRTC exchanges self-signed certificates between peers, whose fingerprints were shared in advance through the signaling channel, allowing each peer to verify the connection during the handshake and negotiate a shared cipher suite before any media begins flowing.

The DTLS handshake establishes the encrypted connection every WebRTC session depends on, and understanding its steps clarifies exactly what verification actually happens.

Step 1: Certificate generation. Each peer generates a self-signed certificate locally, used specifically for this connection rather than issued by a central certificate authority the way a typical HTTPS certificate would be.

Step 2: Fingerprint exchange through signaling. Before the DTLS handshake begins, each peer's certificate fingerprint is exchanged through the signaling channel as part of the session description, giving each side a value to verify against during the handshake itself.

Step 3: ClientHello and ServerHello exchange. The peers exchange handshake messages proposing and agreeing on a cipher suite, the specific combination of cryptographic algorithms that will secure the connection.

Step 4: Certificate verification against the exchanged fingerprint. Each peer verifies the certificate presented during the handshake matches the fingerprint received earlier through signaling, which is what prevents a man-in-the-middle attacker from substituting a different certificate during the handshake itself.

Step 5: Key material establishment. Once the handshake completes, both peers hold the shared key material needed to encrypt the connection, which then feeds directly into how SRTP secures the actual media.

This design, using self-signed certificates verified against a fingerprint exchanged separately, is why signaling channel security matters so directly to WebRTC's overall security. A compromised signaling channel could allow an attacker to substitute their own fingerprint during that exchange.

SRTP in WebRTC: How Media Gets Encrypted

SRTP encrypts WebRTC media using key material derived directly from the completed DTLS handshake, through a mechanism defined in the DTLS-SRTP extension. Every encrypted media packet also carries an authentication tag and sequence information that provides replay protection.

SRTP, Secure Real-time Transport Protocol, handles the actual encryption of audio and video media once the DTLS handshake has established the necessary key material.

Key derivation from DTLS. Rather than negotiating separate encryption keys for media, SRTP derives its keys directly from the completed DTLS handshake, through a mechanism formally defined in IETF RFC 5764, the specification governing how DTLS and SRTP work together in exactly this context.

Per-packet authentication. Every SRTP packet includes an authentication tag, allowing the receiving peer to verify the packet has not been tampered with in transit, in addition to the confidentiality encryption already provides.

Replay protection. SRTP tracks packet sequence information specifically to detect and reject replayed packets, preventing an attacker from capturing and re-sending a previously valid encrypted packet to disrupt or manipulate a session.

This combination, confidentiality through encryption, integrity through authentication tags, and replay protection through sequence tracking, is what SRTP contributes specifically to WebRTC's overall media security beyond encryption alone.

WebRTC's Built-In Permission Model: getUserMedia and User Consent

WebRTC requires explicit user consent through the getUserMedia API before any application can access a device's camera or microphone, a browser-enforced permission boundary that operates independently of the encryption layer and cannot be bypassed by application code alone.

WebRTC security extends beyond encryption into a permission model most users interact with directly without necessarily recognizing it as a security feature.

The getUserMedia API, which an application calls to request camera or microphone access, requires explicit user consent enforced at the browser level, not just the application level. A website cannot silently activate a user's camera or microphone without that browser-level permission prompt appearing, a protection that exists independently of whether the resulting connection is later encrypted correctly.

This permission model matters as a distinct security layer because it protects against a different category of risk than encryption does. Encryption protects data in transit from interception. The permission model protects against unauthorized access to the device's capture hardware in the first place, a meaningfully different threat.

ICE, STUN, TURN, and IP Address Exposure

ICE negotiation, the process WebRTC uses to establish a connection path between peers, can expose local and public IP address information as a byproduct of that negotiation, a privacy consideration browsers increasingly mitigate through mDNS obfuscation of local network addresses specifically.

ICE, Interactive Connectivity Establishment, is the process WebRTC uses to find a viable path between two peers, trying direct connections first and falling back to a TURN relay when necessary. That process has a security and privacy dimension worth understanding on its own.

IP address exposure during negotiation. Gathering ICE candidates can reveal a device's local network IP address and, depending on configuration, its public IP address to the other peer as part of establishing the connection, information that was not otherwise part of the application's data.

mDNS obfuscation for local addresses. Modern browsers increasingly obfuscate local IP addresses during ICE negotiation using mDNS, replacing the actual local address with a randomized, non-identifying value for that purpose, specifically mitigating local network exposure rather than every IP-related privacy concern.

STUN and TURN server trust. The STUN and TURN servers a WebRTC application relies on to establish and relay connections need to be trusted infrastructure, since a malicious or compromised STUN or TURN server sits in a position to observe connection metadata, even though it cannot decrypt SRTP-protected media content itself.

Build Zero-Trust WebRTC Infrastructure

Consult an Architect

Signaling Channel Security: The Part WebRTC Doesn't Handle

WebRTC's specification does not define or secure the signaling channel used to exchange connection setup information, including the DTLS certificate fingerprint, which means signaling security is entirely the implementing application's responsibility, typically addressed through a secured transport such as WSS combined with proper authentication.

This is worth restating directly because it is the single most consequential gap in WebRTC's own security guarantees. WebRTC defines how media and data get encrypted once a connection exists. It does not define, or secure, the signaling channel used to establish that connection in the first place.

Since the DTLS certificate fingerprint exchange happens over this same signaling channel, a compromised or unsecured signaling channel undermines the verification step the entire DTLS handshake depends on. This makes signaling security a direct prerequisite for the media encryption guarantees that follow it, not a separate, lower-priority concern.

Practical signaling security requires a secured transport, such as WSS rather than unencrypted WebSocket, combined with proper authentication of who is allowed to participate in a given signaling exchange, and protection against replay or injection of signaling messages by an unauthorized party.

WebRTC Threat Model: What's Protected by Design vs What Requires Application-Level Hardening

WebRTC's threat model protects media and data channel content through mandatory encryption and device access through browser-enforced permissions, but explicitly does not protect the signaling channel, TURN credential exposure, or misconfiguration risks, all of which require deliberate application-level hardening.

This table is the practical summary worth internalizing: WebRTC handles the parts of security tied directly to its own protocol operation extremely well, while leaving the surrounding infrastructure, signaling and credential management specifically, entirely to whoever builds on top of it.

Common WebRTC Security Vulnerabilities and Misconfigurations

The most common WebRTC security failures trace back to implementation choices outside the protocol itself: exposed or long-lived TURN credentials, weak or missing signaling authentication, and debug configurations, such as disabled certificate verification, left active in production.

• Exposed or long-lived TURN credentials. TURN credentials embedded directly in client-side code or never rotated create a persistent exposure risk, since a leaked credential remains valid indefinitely rather than expiring on a defined schedule.

• Weak or missing signaling authentication. A signaling server that does not properly authenticate who is allowed to join a given session or exchange signaling messages creates an opening for unauthorized session hijacking or eavesdropping on connection setup.

• Debug configurations left active in production. Development environments sometimes disable certificate verification or other checks for easier debugging, a configuration that must be explicitly removed before production deployment rather than assumed to be automatically disabled.

• Overly permissive TURN server access. A TURN server configured without appropriate rate limiting or access scoping can be abused as an open relay, a resource exhaustion and abuse risk separate from the encryption of the traffic it relays.

None of these vulnerabilities represent a flaw in WebRTC's mandatory encryption itself. All of them represent implementation and infrastructure decisions that sit outside what the protocol specification guarantees.

Enterprise Use Cases: WebRTC Security Hardening by Industry

WebRTC security hardening priorities differ by industry based on the specific consequence of a gap in the areas WebRTC leaves to the application. Healthcare, financial services, and legal each have a distinct reason to prioritize signaling and credential hardening specifically.

Healthcare

• Problem: Telemedicine platforms need assurance that the areas WebRTC leaves unaddressed, particularly signaling channel security, do not create a gap in an otherwise well-encrypted system handling protected health information.

• Solution: Implementing authenticated, WSS-secured signaling with strict session validation closes the specific gap that would otherwise undermine the DTLS handshake's certificate verification step.

• Outcome: The full security chain, from signaling through DTLS verification to SRTP-encrypted media, remains intact rather than relying on media encryption alone while leaving an unaddressed gap earlier in the connection setup process.

Financial Services

• Problem: Financial institutions running WebRTC-based advisory or trading floor communications need strict control over TURN credential exposure, since a leaked credential could allow unauthorized relay access to sensitive call infrastructure.

• Solution: Implementing short-lived, scoped TURN credentials with regular rotation, rather than static long-lived credentials, limits the exposure window if a credential is ever compromised.

• Outcome: Credential exposure risk stays bounded to a short validity window, rather than persisting indefinitely if a static credential were ever leaked or compromised.

Legal Services

• Problem: Legal teams relying on WebRTC-based video for privileged client conversations need confidence that debug configurations or signaling weaknesses have not been inadvertently left active in whatever platform they use.

• Solution: Requesting a specific security configuration review from any WebRTC-based platform vendor, covering signaling authentication and confirmation that no debug-mode configuration remains active in production, provides direct verification rather than an assumption.

• Outcome: Verified configuration review gives legal teams documented confidence in the platform's actual security posture, supporting their own confidentiality obligations with specific evidence rather than general reassurance.

Decision Tree: What WebRTC Security Gaps Should You Prioritize Closing First?

[ START ]
     │
    ▼
  ┌──────────────────────────────────────────────────────────────────┐
  │ CRITERIA: Signaling & TURN Credential Check                      │
  │ Is your signaling channel secured with authenticated WSS, and    │
  │ are TURN credentials short-lived and scoped?                     │
  └──────────────────────────────────────────────────────────────────┘
     │
     ├──► YES ──► [ VERIFIED ]
     │            Signaling and credential security are already addressed.
     │            Focus next on ICE privacy and debug configuration review.
     │
     └──► NO  ──► [ ACTION REQUIRED ]
                  Prioritize closing these two specific gaps first, since
                  they undermine the DTLS verification step and create
                  persistent credential risk.

RTC LEAGUE WebRTC Security Hardening Framework v1.0

A four-step framework for hardening WebRTC security beyond the protocol's default guarantees, covering signaling channel review, TURN credential management, debug configuration audit, and ICE privacy assessment, in the order they should be addressed.

Assuming WebRTC's mandatory encryption alone satisfies a complete security posture is a common source of gaps discovered only after a review or incident. The RTC LEAGUE WebRTC Security Hardening Framework v1.0 orders the hardening process correctly.

Step 1: Secure and authenticate the signaling channel. Confirm signaling runs over WSS with proper authentication, since this protects the fingerprint exchange the DTLS handshake's verification step depends on directly.

Step 2: Implement short-lived, scoped TURN credentials. Replace any static, long-lived TURN credentials with short-lived, scoped alternatives rotated on a defined schedule.

Step 3: Audit for debug configurations left active in production. Explicitly review for disabled certificate verification or other debug-mode settings that should never remain active in a production deployment.

Step 4: Assess ICE privacy exposure for the deployment's specific client base. Confirm mDNS obfuscation is functioning as expected across the browsers and clients the deployment actually supports, rather than assuming universal coverage.

Outcome: Completing this sequence closes the specific gaps WebRTC's specification leaves to the application, producing a security posture that matches the strength of WebRTC's mandatory encryption rather than undermining it through an unaddressed surrounding weakness.

Deploy Hardened WebRTC Real-Time Architecture

Partner with RTC LEAGUE

RTC LEAGUE's Approach to WebRTC Security

RTC LEAGUE addresses signaling authentication, TURN credential rotation, and debug configuration review explicitly as part of every WebRTC deployment, rather than relying on WebRTC's mandatory encryption alone to represent a complete security posture.

RTC LEAGUE builds WebRTC deployments with the areas covered in this guide addressed explicitly, not left as an assumption. Signaling channels run over authenticated, secured transport. TURN credentials are scoped and rotated rather than static. Debug configurations are reviewed and confirmed removed before any production deployment.

This approach reflects the core argument of this guide directly: WebRTC's mandatory DTLS-SRTP encryption is a strong foundation, but a complete security posture requires deliberately addressing the specific areas the specification leaves to the implementing application.

Conclusion and Recommendation

WebRTC security combines protocol-mandated encryption, DTLS for key exchange and data channels, SRTP for media, with a browser-enforced permission model for device access, both strong guarantees by design. The gaps that actually undermine WebRTC security in practice sit outside the protocol itself: signaling channel weaknesses, exposed TURN credentials, and debug configurations left active in production.

Understanding the DTLS handshake and SRTP key derivation mechanics clarifies exactly why signaling security matters so directly, since the certificate fingerprint verification the entire encryption chain depends on happens through that same signaling exchange.

The clearest recommendation for WebRTC security: treat mandatory encryption as the foundation, not the complete picture, and explicitly harden signaling authentication, TURN credential management, and production configuration review as deliberate, ongoing practices rather than one-time assumptions.