4. Security for WebRTC Applications

WebRTC applications determine the security policies for the sessions they create. This section describes the security mechanisms available to applications and how they should be used.

To prevent "calling card" attacks (Section 3.1), WebRTC requires that the receiving endpoint explicitly consent to receive traffic. This is accomplished via the Interactive Connectivity Establishment (ICE) protocol [RFC8445]. Before sending any non-ICE traffic to a destination, a WebRTC endpoint MUST verify that the destination has responded to an ICE STUN binding request. This proves that the destination is active and willing to receive traffic on that port.

To prevent spying (Section 3.2), browsers MUST require explicit user consent before allowing a site to access the camera or microphone. This consent SHOULD be specific to the origin requesting access and SHOULD be revocable.

4.3 Secure Communication

To provide confidentiality and integrity, all WebRTC media and data traffic MUST be encrypted and authenticated.

For media (audio/video), SRTP [RFC3711] is used, keyed via DTLS-SRTP [RFC5764].
For data channels, SCTP over DTLS [RFC8261] is used.

This ensures that attackers on the network path cannot read or modify the communication.

4.4 Identity

While DTLS provides authentication of the channel, it does not inherently identify the user at the other end. WebRTC provides mechanisms for "Identity Providers" (IdPs) to assert the identity of users and bind those identities to the DTLS certificates used for the call. This allows users to verify who they are communicating with, independent of the signaling service.