WebRTC Security: Signaling, DTLS-SRTP, TURN & Access | Callaba
More live video workflow notes and product updates.
WebRTC encrypts media in transit, but a secure call still depends on who may join, what signaling messages they may send, which network paths are exposed, where media is decrypted, and how operators respond to abuse. Treating DTLS-SRTP as the whole security model leaves the application, TURN service, room policy, recording, and media server outside the review.
Security crosses the application and media planes
Where Callaba fits in the WebRTC security model
Callaba Video Calls provides managed browser rooms with participant tokens, room lifecycle controls, chat, screen sharing, webinar behavior, and optional recording. Its API separates administrative x-access-token calls from the participant join token, and exposes instance-wide secure WebSocket and TURN configuration. This is a room workflow, not proof of end-to-end encryption through an SFU, a general identity provider, or a security guarantee for an arbitrary WebRTC application.
| Control | Callaba action | Separate responsibility |
|---|---|---|
| Room administration | Keep create, update, start, stop, and global configuration calls on a trusted backend | Protect the administrative token, operator accounts, audit trail, and change approval |
| Participant entry | Resolve the active room and issue a participant token close to join time | Authenticate the user and decide the allowed room, identity, role, and expiry |
| Network traversal | Configure secure WebSocket and TURN settings, then test real networks | TURN geography, credentials, firewall policy, capacity, and relay abuse controls |
| Recording or output | Use a documented room or participant output only after the room is accepted | Consent, retention, downstream access, and encryption at rest |
A minimal security acceptance run creates one non-production room, joins two authorized browsers using independently issued tokens, rejects an invalid token, forces the supported relay path, and verifies that stopping the room prevents a fresh join. Record only safe identifiers and timings; never put tokens in the test report.
Start with assets, actors, and trust boundaries
List the media, screen shares, chat, participant identity, room metadata, ICE candidates, recordings, transcripts, administrative controls, and service credentials. Then name who can produce, view, moderate, record, export, or delete each asset. A host, guest, anonymous viewer, support engineer, backend service, and compromised browser do not share one risk profile.
The WebRTC fundamentals guide owns the protocol introduction, while WebRTC server architecture owns capacity and topology. This page asks what each component can learn or change and which control limits it.
Signaling needs normal web-application security
WebRTC does not prescribe an application signaling protocol. Offers, answers, ICE candidates, room membership, mute state, and lifecycle events commonly travel through HTTPS or secure WebSockets. Authenticate the session, authorize every state-changing message, validate schema and size, apply origin and rate policies, and prevent one participant from naming another participant's room or role.
Do not place administrative tokens, TURN long-term secrets, or reusable room credentials in browser bundles. Use short-lived, narrowly scoped participant credentials. Log token issuance and decision outcomes with a safe correlation identifier, not the credential itself.
DTLS-SRTP protects media in transit, with a termination boundary
The W3C WebRTC specification requires encrypted media transport with strong per-session keying. The IETF WebRTC Security Architecture describes the broader security model.
In direct peer-to-peer communication, the negotiated media protection is between the endpoints. When an SFU, gateway, recorder, or compositor participates, document whether it terminates or can access media and what happens next. “Encrypted WebRTC” does not automatically mean that only the human participants can decrypt every frame. If the requirement is end-to-end media encryption across an intermediary, it needs a separately designed and tested mechanism with clear feature trade-offs.
ICE candidates and TURN reveal operational information
ICE tests candidate paths; STUN assists address discovery; TURN relays when direct connectivity is unavailable or policy requires it. Candidate handling and IP exposure are privacy concerns, while a public relay can become an abuse and cost surface. Require authenticated TURN use, short credential lifetimes, transport limits, rate controls, monitoring, and enough regional capacity for the forced-relay case.
Test from enterprise Wi-Fi, mobile carrier networks, VPNs, and a UDP-restricted path. A call that works on one office LAN does not establish relay readiness. Keep selected candidate type, join-to-media time, relay region, and failure category in operational telemetry.
Room authorization must be more specific than “has a token”
| Question | Control to define | Failure to test |
|---|---|---|
| Which room? | Bind the credential to the intended room or tenant | Reuse against another room |
| Which identity? | Bind a server-verified subject and safe display name | Impersonate the host or another guest |
| Which actions? | Separate join, publish, subscribe, moderate, record, and export permissions | Escalate from viewer to publisher or moderator |
| For how long? | Use short validity and explicit revocation or room-stop behavior | Join with expired or revoked credentials |
Browser camera and microphone permission is a user-agent control, not application authorization. The page still decides where captured media is sent after the user grants access. Make the destination, recording state, and participant role understandable in the UI.
Example: a guest link works after the meeting has ended
A participant forwards yesterday's URL and a second browser reaches the room lookup flow. The first evidence is token issuance time, expiry, room state, subject, and authorization result—not packet loss. If the credential is still accepted after the intended window, the root cause sits at the identity and room-lifecycle boundary. Stop the room, revoke or expire the join path, preserve safe audit IDs, and verify that a fresh unauthorized join now fails.
Recording changes the security and privacy model
Recording converts an ephemeral session into a retained asset. Define notice and consent, who may start it, which tracks are captured, storage location, encryption at rest, retention, legal hold, access logs, export, and deletion. Treat NDI, SRT, RTMP, or other room outputs as new delivery boundaries with their own recipients and secrets.
The recording guide covers the operator workflow. It does not decide your lawful basis or retention policy. Those decisions belong to the organization responsible for the meeting and its participants.
Operational telemetry must avoid becoming a new leak
Useful records include safe user and room IDs, authentication decision, join phase, selected candidate type, relay region, media start time, disconnect category, role changes, recording state, and administrative changes. Avoid full SDP bodies, raw ICE candidates, tokens, private chat, or media in routine logs unless a narrowly approved diagnostic process requires them.
Alert on repeated failed joins, token reuse outside policy, unusual room creation, TURN bandwidth anomalies, moderator changes, recording starts, and administrative configuration changes. Define who can inspect each record and how long it is kept.
A security commissioning runbook
- Map the trust boundaries. Browser, application backend, signaling, SFU/media service, TURN, recorder, and output systems.
- Exercise roles. Host, publisher, viewer, moderator, and denied user each attempt allowed and forbidden actions.
- Force difficult networks. Confirm supported relay behavior without exposing long-lived TURN credentials.
- Test lifecycle. Expire a token, stop a room, remove a participant, and verify the resulting join and media behavior.
- Inspect media termination. Document which services can access clear media and why.
- Commission incident evidence. Ensure one alert can identify the failed boundary without logging secrets.
WebRTC security FAQ
Is WebRTC media always encrypted?
Browser WebRTC uses encrypted transports, but you still need to identify the endpoints and any media service where protection terminates. Encryption in transit is not the same as end-to-end encryption between human participants.
Does HTTPS secure the whole call?
No. HTTPS protects the web and signaling transport. Room authorization, media transport, TURN, server-side media access, recording, and outputs each need their own controls.
Should TURN credentials be placed in JavaScript?
Do not expose a reusable long-term secret. Issue time-limited credentials through an authorized backend and monitor relay use, capacity, and abuse.
What is the fastest useful denial test?
Attempt to join the wrong room with an expired or invalid participant credential, verify a clear denial, and confirm that the failure reveals no token, internal service detail, or another participant's data.