Skip to content
On this pageOPEN
  1. 01Goal
  2. 02Plain-language concept
  3. 03Interactive diagram
  4. 04Behind the scenes
  5. 05Code walkthrough
  6. 06Do & don't
  7. 07Practice
  8. 08Quick quiz
  9. 09Key takeaways
  10. 10Common errors
LESSON 13Advanced28 min read

Security & privacy

Encryption boundaries, permission hygiene, IP privacy, TURN credentials, and the threats WebRTC does not solve for you.

#security#DTLS#TURN auth#IP leak#permissions
01

Goal

  • 01Map the real security boundaries in a WebRTC system and stop assuming DTLS solves every threat.
  • 02Authorize signaling, protect TURN credentials, and treat browser media permissions as a product surface.
  • 03Choose when relay-only ICE or true end-to-end encryption is necessary for privacy.
02

The concept, plainly

WebRTC encrypts media in transit with DTLS-SRTP and encrypts data channels over DTLS. That is strong protection against passive network observers and gives each hop an authenticated peer certificate. It does not, by itself, authenticate the humans in the call, authorize room membership, make signaling trustworthy, or protect media after an SFU terminates the hop.

Signaling is a high-value target. Every join, offer, answer, and candidate relay must be authorized server-side. Validate schemas and sizes, bind a socket connection to an authenticated principal, and check that a sender may target the peer or room in the message. Never trust a client-supplied peer id. Rate-limit joins and message relays to reduce resource exhaustion and scanning.

TURN credentials are not room passwords. Use short-lived credentials from coturn's shared-secret scheme, scope them as tightly as the deployment allows, and never ship the static secret to the browser. A TURN server that allows arbitrary allocations can be abused for traffic relay and amplification. Restrict ports, realms, quotas, and transports; monitor allocation counts and egress.

ICE candidates reveal network addresses to the other participants and, through signaling, to your server. Modern browsers often use mDNS host candidates, but public reflexive addresses can still be exposed. If IP privacy is a requirement, force relay-only candidates through TURN and avoid leaking SDP/candidate logs. This raises latency and cost, so it is a product decision, not a free default.

Media permissions are capabilities granted to an origin. Request the smallest scope, make the local preview obvious, and stop tracks on leave. Screen shares may expose notifications, private tabs, or an entire desktop; default to a window or tab where the browser allows it, and never auto-share. Revoke unused devices. Treat remote media as untrusted input: validate data-channel messages, cap sizes, and never inject them into the DOM as HTML.

End-to-end encryption is a separate design. A standard SFU terminates DTLS-SRTP, so it can see decrypted media. If participants must be protected from the server itself, use a documented frame-level E2EE approach such as insertable streams with a key-management protocol the server cannot bypass. Do not claim E2EE without verifying the topology, the keys, and the threat model.

03

See it move

PLAY / PAUSE / STEP

Interactive diagram

Trust boundaries in a real-time session

permissiontokensessionSDP + candidatesrelayed SRTPendpoint hopframeshide addressesBROWSERParticipanthuman + deviceBROWSERBrowserpermission boundarySERVERAuthenticationwho is this socket?SERVERSignalingauthorize every relayNETWORKDTLS-SRTPencrypted hopSERVERTURNrelay + metadataPEERRemote peeruntrusted inputPROCESSE2EE designonly if promisedSTORAGEPrivacy moderelay-only candidates
STEP 01 / 08authz

Authenticate before joining

The signaling socket must be bound to a principal. Anonymous labs can use device ids, but production rooms still need authorization.

Encryption protects the hop. Authorization, key management, and topology decide what the server and peers can see.

04

Behind the scenes

01

The signaling server is an authorization service

Even a simple room server should bind socket ids to a session, reject join when the room is full or unauthorized, verify the sender is in the room before relaying an offer, and stop sending messages after a socket closes. Those checks are cheap and prevent the most common cross-room leaks. Rate limits and payload caps prevent a single client from exhausting memory.

02

Permissions can be revoked outside your UI

The user can revoke camera access in browser settings, unplug a microphone, or stop a screen share from browser chrome. The page must handle track.onended and devicechange. A permission prompt is not a one-time contract. A production interface should show capture state honestly and offer recovery.

03

IP privacy is a relay decision

If a peer must not learn another participant's public address, direct ICE candidates leak it. Forcing relay candidates through TURN hides the endpoint addresses from peers, but your TURN provider still sees the allocation metadata. Consider the threat model: protecting against the other participant, your own server, or a network observer are different problems.

05

Code walkthrough

COPY-READY

Never relay to a peer the sender cannot address. Bind the socket to a principal, check room membership, and cap payloads.

server/signaling-auth.ts
type Session = { peerId: string; room: string; principalId: string };


export function authorizeRelay(
  session: Session,
  targetPeerId: string,
  roomPeers: Map<string, { session: Session }>,
) {
  const target = roomPeers.get(targetPeerId);
  if (!target) throw new Error("TARGET_NOT_FOUND");
  if (target.session.room !== session.room) throw new Error("CROSS_ROOM_DENIED");
  if (target.session.principalId === session.principalId) {
    throw new Error("SELF_TARGET_DENIED");
  }
  return target;
}


const MAX_SDP_BYTES = 100_000;
const MAX_CANDIDATE_BYTES = 2_000;


export function enforcePayloadLimit(type: "offer" | "answer" | "ice", raw: string) {
  const limit = type === "ice" ? MAX_CANDIDATE_BYTES : MAX_SDP_BYTES;
  if (new TextEncoder().encode(raw).byteLength > limit) {
    throw new Error("PAYLOAD_TOO_LARGE");
  }
}
06

Do and don't

Do

  • Authorize at the server boundary

    Bind socket identity, check room membership and target, cap payloads, and rate-limit joins and relays.

  • Use expiring TURN credentials

    Mint HMAC credentials server-side, rotate secrets, and monitor relay allocations and egress.

  • Validate remote data

    Cap file sizes, parse JSON safely, render text as text, and ignore malformed messages without crashing the call.

  • State the encryption model

    Say 'transport encrypted' or 'end-to-end encrypted' only when the topology and key design support it.

Don't

  • Don't trust client peer ids

    The server issues and checks identity. A client-supplied target can otherwise relay into rooms it does not belong to.

  • Don't auto-share screens

    Display capture is a separate, explicit permission. Start from a window/tab where possible and show exactly what is shared.

  • Don't upload raw SDP and candidates to analytics

    They can contain addresses and session details. Redact, aggregate, and set retention.

  • Don't call DTLS-SRTP E2EE in an SFU product

    A standard SFU terminates the hop. If the server must not see media, use a separate frame-level E2EE design.

07

Practice

Hands-on lab

Inspect the IP and permission surface

The 1:1 lab exposes candidate addresses, the selected path, permission errors, and data-channel inputs. Use it to see what a peer and a server can learn.

  1. 1Connect two tabs and identify every candidate address revealed to the other peer.
  2. 2Set TURN-only with a relay configured and confirm the selected pair is relayed.
  3. 3Deny camera permission and read the distinct error message; then use the test feed.
  4. 4Send a malformed or oversized file and confirm the lab rejects it rather than freezing.
Open the security-adjacent lab

Solo? Loopback still shows candidate types and permission behavior, but privacy-mode differences are most meaningful with a second network path.

08

Quick quiz

Knowledge check

0 of 5 answered

0%
  1. 01

    What does DTLS-SRTP guarantee in a standard SFU topology?

  2. 02

    Why must a signaling server authorize relay targets?

  3. 03

    How should TURN credentials reach the browser?

  4. 04

    What does iceTransportPolicy: 'relay' do?

  5. 05

    Which action best protects a data-channel file receiver?

Pick one answer per question to see instant feedback.
09

Key takeaways

  1. DTLS-SRTP protects media hops; authorization and key management decide the actual trust model.01
  2. The signaling server must authenticate sockets and authorize every relay, join, and target.02
  3. TURN credentials must be short-lived, server-minted, and monitored for abuse.03
  4. IP privacy, screen sharing, remote data, and E2EE each need an explicit product decision.04
10

Common errors and fixes

Terms in this lesson

DTLSSRTPTURNIP leak

Done with this lesson?

Mark it complete, then keep the thread.

PREVIOUS

WebRTC topologies at scale

NEXT

Debugging real-time systems