Security
Security in WebRTC is not optional. Every connection is encrypted, and there is no setting to turn it off. Media, data, and the keys that protect them are all secured by the standard itself.
What it enables
Confidential, tamper-resistant communication with no extra configuration. A developer cannot accidentally ship an unencrypted WebRTC connection, because the unencrypted path does not exist. Add to that a permission model that keeps the camera, microphone, and screen under user control, and a transport that is private end-to-end in the direct peer-to-peer case.
How it works (high level)
Two encryption layers cover the two kinds of traffic. Media travels over SRTP, the secure form of RTP. Data channels run over DTLS, the datagram form of TLS. Both draw their keys from a DTLS handshake the peers perform when the connection opens.
Identity is verified with fingerprints. Each peer's certificate produces a fingerprint that is carried in the SDP during signaling. After the DTLS handshake, each side checks that the certificate it actually negotiated matches the fingerprint it was promised. If the signaling channel is trusted, this confirms the peer at the other end is the one described in the offer or answer, which blocks a man-in-the-middle from quietly substituting itself.
The browser guards hardware behind explicit permission. Camera, microphone, and screen capture each require a user prompt, and screen capture additionally forces the user to choose the surface. Pages must be served over HTTPS for these APIs to work at all.
One caveat: when traffic routes through a media server, such as an SFU for group calls or streaming, the connection is encrypted to that server, not strictly end-to-end. In the direct peer-to-peer case, only the two peers hold the keys.
Where it's used
Every WebRTC feature relies on this. Calls, data channels, file transfer, and streaming all inherit mandatory encryption and the permission model without any application code.