WebRTC is secure by design at the transport layer: standards-compliant connections encrypt audio and video with SRTP, use DTLS to establish keying material, and protect data channels with DTLS. That does not make an entire WebRTC application secure automatically. User authentication, authorization, signaling, TURN access, server configuration, recordings, application data, and any media processing outside the encrypted connection remain the operator’s responsibility.
This guide explains the WebRTC security architecture, corrects common misconceptions about CORS and end-to-end encryption, and gives developers a practical checklist for protecting real-time communications.
Is WebRTC Secure?
Yes, WebRTC requires encrypted transport for standards-compliant browser connections. Web browsers do not offer an option to send WebRTC media streams as unencrypted RTP. The peers negotiate cryptographic parameters and authenticate the DTLS exchange using certificate fingerprints carried in the session description. Audio and video then travel as encrypted SRTP packets.
That answer needs an important qualification. WebRTC protects traffic between the endpoints of each WebRTC connection. If a media server terminates one connection and creates another, each leg can be encrypted while the server can still access the media in between. This is necessary for many functions, including transcoding, recording, compositing, moderation, and protocol conversion. It is transport encryption, not necessarily end-to-end encryption between the original publisher and every viewer.
WebRTC security therefore has two parts:
- Built-in protocol protection: encrypted media, encrypted data channels, and authenticated key establishment.
- Application and infrastructure protection: secure signaling, identity, permissions, access control, credential management, server hardening, storage security, monitoring, and incident response.
The protocol supplies a strong foundation. The application still determines who may join, what each user may publish or watch, and what happens to media after it reaches a trusted service.
WebRTC Security Architecture at a Glance
The main security layers are easier to understand when separated by responsibility.
No single row replaces the others. A securely encrypted media connection can still be exposed by a stolen session token, an overly broad authorization rule, a vulnerable signaling service, or a public recording bucket.
How WebRTC Encryption Works
WebRTC establishes a connection in stages. Signaling exchanges descriptions and connectivity information. ICE finds a viable network path. DTLS authenticates the peers and establishes keying material. SRTP protects audio and video, while DTLS protects data-channel traffic.
SDP and Certificate Fingerprints
The Session Description Protocol (SDP) describes media capabilities and connection parameters. An offer and answer can include codecs, media directions, ICE information, and a fingerprint of the certificate that a peer will use during the DTLS handshake. Protecting this key exchange helps prevent man-in-the-middle substitution.
WebRTC does not prescribe how an application exchanges SDP. The application may use HTTPS, secure WebSockets, or another signaling mechanism. Because the certificate fingerprint travels through signaling, an attacker who can alter signaling may be able to substitute connection details. Protecting and authenticating the signaling path is therefore essential even though signaling does not carry the media itself.
DTLS and Key Establishment
DTLS stands for Datagram Transport Layer Security. It provides TLS-style security for datagram transports and is used by WebRTC peers to authenticate the connection and derive keying material. The peers compare the certificate presented during the DTLS handshake with the fingerprint exchanged through SDP.
For media, WebRTC uses the DTLS-SRTP mechanism standardized in RFC 5764. DTLS establishes the material from which SRTP keys are derived. It is more accurate to describe DTLS as a datagram-oriented security protocol based on TLS than as a subset of TLS.
SRTP for Audio and Video
Secure Real-time Transport Protocol, or SRTP, provides confidentiality, message authentication, and replay protection for RTP media. WebRTC uses SRTP for audio and video and SRTCP for the associated control traffic. The encryption is handled by the WebRTC implementation rather than by application JavaScript.
SRTP does not encrypt the signaling service, application API, stored recording, or administrative interface. Those systems need their own controls. SRTP also should not be confused with SRT, the Secure Reliable Transport protocol used in many contribution workflows.
Data-Channel Protection
WebRTC data channels do not use SRTP. They carry SCTP over DTLS, so messages are encrypted in transit between the WebRTC peers. Applications must still validate the content they receive. Treat data-channel messages as untrusted input, enforce authorization, limit message sizes and rates, and never assume that encryption proves a user is allowed to perform an action. The same principle applies to media streams: encryption protects transport, not business permissions.
For a standards-level description of the threat model and security properties, see the IETF’s WebRTC Security Architecture.
HTTPS, Permissions, and Device Access
Browsers restrict camera and microphone access because those media devices expose sensitive information. The getUserMedia() API is available only in a secure context, with limited exceptions such as local development, and requires explicit user consent. The user’s browser also shows indicators while a camera or microphone is in use.
Serve the application over HTTPS with a valid certificate. Request only the devices and capabilities the feature needs, make the request in response to a clear user action, and provide a useful experience when permission is denied. Applications embedded in an iframe also need an appropriate Permissions Policy and iframe configuration before the embedded origin can request access.
HTTPS protects delivery of the application and its calls to HTTPS endpoints. It does not replace WebRTC’s media encryption. The page, signaling channel, and peer connection are separate security layers that work together.
Signaling Security, CORS, and Secure WebSockets
Signaling coordinates a WebRTC session, but signaling is not defined by the WebRTC specification. An application usually exchanges offers, answers, ICE candidates, and session-control messages through an HTTPS API or secure WebSocket connection.
Protect the signaling server or service as carefully as any other authenticated application endpoint:
- Use HTTPS or WSS in production.
- Authenticate the user before allowing a publish or subscribe action.
- Authorize the specific room, stream, and role rather than checking only that the user is signed in.
- Use short-lived, narrowly scoped credentials where practical.
- Validate signaling messages and reject unexpected state transitions.
- Apply rate limits and protect session identifiers against guessing and reuse.
- Avoid placing long-lived secrets in client-side code or URLs.
What CORS Does and Does Not Do
Cross-Origin Resource Sharing, or CORS, is a browser mechanism that lets a server state which web origins may read responses to cross-origin requests. It matters when a WebRTC application calls an HTTP API on a different origin. CORS is not a user-authentication system, and an permissive CORS policy does not grant legitimate business authorization by itself.
WebSockets are not governed by the CORS protocol in the same way as fetch() requests. A WebSocket server should validate the Origin header, authenticate the session, and reject origins it does not trust. WSS encrypts the signaling connection in transit, while application authorization decides what that connection may do.
Do not solve cross-origin errors by allowing every origin together with credentials. Maintain an explicit production allowlist and test it whenever domains, CDNs, or application environments change.
ICE, STUN, and TURN Security
Interactive Connectivity Establishment, or ICE, gathers possible network paths and tests candidate pairs until the peers find a working route. Candidates can represent a local interface, an address discovered through STUN, or a relay allocated through TURN.
STUN helps a client learn its server-reflexive address. TURN relays traffic when a direct path cannot be established or when policy requires a relay. TURN is not simply a performance fallback: it is an operational dependency for users behind restrictive NATs and firewalls. Because TURN and WebRTC connections must operate across varying network conditions, understanding the relationship between available bandwidth and delivery delay is also important; see our guide to bandwidth vs latency.
For production deployments:
- Operate sufficient TURN capacity in the regions your users need.
- Use authenticated, preferably time-limited TURN credentials instead of publishing a permanent shared password.
- Restrict allowed transports and relay behavior to the requirements of the application.
- Monitor allocation volume, bandwidth, authentication failures, and unusual geographic patterns.
- Keep TURN software patched and protect its administrative interfaces.
- Test UDP and TCP/TLS relay paths from restrictive networks.
ICE candidates can disclose network information needed to establish connectivity. Applications should avoid logging or exposing candidate data unnecessarily and should apply their normal privacy, retention, and access policies to signaling logs.
What WebRTC Does Not Secure Automatically
WebRTC’s mandatory transport encryption solves an important problem, but it is not a complete application security model.
Identity and Authorization
Encryption protects a connection; it does not decide whether the person on that connection is allowed to publish a stream, enter a private room, control a camera, or view premium content. Map authenticated identities to explicit permissions and enforce those permissions on the server for every sensitive action.
End-to-End Encryption Through Media Servers
A selective forwarding unit, media server, or streaming platform may terminate WebRTC connections. Each client-to-server leg can be encrypted, but the server may access unencrypted media in memory. If the threat model requires the server to be unable to read media, the application needs an additional end-to-end encryption design, compatible clients, key management, and a clear decision about which server-side features must be sacrificed or adapted.
Do not label a service end-to-end encrypted merely because every network hop uses DTLS-SRTP. State the trusted endpoints and where media can be decrypted.
Recordings, Transcoding, and Protocol Conversion
When a platform records, transcodes, composites, analyzes, or converts a WebRTC stream, the media leaves the protection boundary of the original peer connection inside a trusted service. Protect resulting files and intermediate data with encryption at rest, strict access control, retention limits, audit logs, and secure deletion procedures.
Application and Supply-Chain Risks
Cross-site scripting can let malicious code operate with the privileges of the application. Vulnerable dependencies, leaked tokens, weak APIs, exposed dashboards, and insecure cloud storage can undermine an otherwise correct WebRTC connection. Use a Content Security Policy, dependency and container scanning, secure secret storage, timely patching, least-privilege service accounts, and regular security testing.
Metadata and Privacy
Encryption does not hide every fact about a session. Participants and infrastructure may still observe IP addresses, timing, traffic volume, device characteristics, account data, and operational logs. Collect only what the service needs, disclose the purpose, limit retention, and protect access to analytics and support tooling.
How Red5 Fits Into a Secure WebRTC Workflow
Red5 provides live streaming solutions for developers, startups, and enterprises that need to publish, route, and play real-time video. Red5 Cloud is the managed platform option, while Red5 Pro gives teams more control over a self-managed deployment. Both can participate as WebRTC peers in a media workflow and connect browser publishers or subscribers to a larger streaming pipeline.
In this architecture, a browser establishes an encrypted WebRTC connection to a Red5 endpoint. Red5 can then route the stream, create subscriber connections, or perform enabled server-side functions. Each WebRTC leg is protected, but Red5 is a trusted media endpoint rather than an invisible end-to-end-encrypted pass-through. That distinction matters when a workflow includes recording, transcoding, analytics, protocol conversion, or other processing.
Red5 simplifies WebRTC transport and streaming orchestration, but application owners still need to configure HTTPS and secure signaling, authenticate users, authorize publish and subscribe operations, protect TURN credentials, restrict administrative access, patch infrastructure, and secure stored media. Teams using Red5 Pro should follow the current SSL configuration documentation for their deployment. Teams using Red5 Cloud should apply the identity, token, and application controls documented for the managed service.
The open-source Red5 Media Server is a separate product and does not provide the WebRTC capabilities described in this section. Use Red5 Cloud or Red5 Pro when the workflow requires supported WebRTC publishing and playback.
WebRTC Security Checklist
Use this checklist before production launch and repeat it after meaningful architecture or dependency changes.
- Serve every production page and API endpoint over HTTPS with valid, monitored certificates.
- Use WSS or another authenticated, encrypted signaling transport.
- Validate signaling origins and messages; do not treat CORS as authentication.
- Require authentication and enforce stream-, room-, and role-level authorization on the server.
- Use short-lived, scoped session and TURN credentials where practical.
- Provide TURN capacity and test relay paths from restrictive networks.
- Keep media servers, TURN servers, dependencies, operating systems, and containers patched.
- Restrict administrative interfaces by network and identity, with strong multifactor authentication where supported.
- Protect recordings, thumbnails, transcripts, logs, and analytics data at rest and in transit.
- Apply rate limits, abuse controls, input validation, and monitoring to signaling and data channels.
- Decide whether transport encryption is sufficient or true end-to-end encryption is required.
- Document trusted endpoints, media-processing boundaries, data retention, and incident procedures.
- Test permission-denied paths, expired credentials, revoked users, certificate renewal, and TURN failure.
- Run security reviews and penetration tests that cover the application, not only the WebRTC transport.
FAQs
Is WebRTC encrypted by default?
WebRTC requires encrypted transport for standards-compliant connections. Audio and video use SRTP with keying material established through DTLS-SRTP, while data channels use SCTP over DTLS. This protects traffic between the endpoints of each peer connection, but it does not automatically protect recordings, signaling data, application APIs, or media inside a trusted server.
Is WebRTC end-to-end encrypted?
WebRTC is encrypted between the endpoints of each peer connection. In a direct peer-to-peer call, those endpoints may be the users’ devices. When a media server terminates separate connections, every leg may be encrypted while the server can access the media. True end-to-end encryption requires an additional design that keeps keys away from the server.
What is the difference between DTLS and SRTP in WebRTC?
DTLS authenticates the WebRTC peers and establishes keying material. SRTP uses derived keys to protect real-time audio and video, including confidentiality, integrity, and replay protection. Data channels follow a different path: SCTP messages are protected directly by DTLS rather than by SRTP.
Does WebRTC require HTTPS?
Browser camera and microphone access through getUserMedia()\ generally requires a secure context, so production applications should be served over HTTPS. Secure delivery also protects the application’s code and HTTPS APIs. HTTPS does not carry the WebRTC media itself; the peer connection uses its own DTLS, SRTP, and ICE mechanisms.
Are STUN and TURN secure?
STUN and TURN are connectivity tools, not complete application-security systems. TURN can authenticate allocations and can operate over protected transports, but operators must secure credentials, patch the service, restrict abuse, and monitor bandwidth. Use time-limited credentials and test the relay paths required by your users and networks.
Does CORS secure a WebRTC application?
No. CORS controls whether browser JavaScript from one origin can read certain cross-origin HTTP responses. It does not authenticate users or authorize access to a stream. A secure WebRTC application also needs protected signaling, origin validation, authentication, server-side authorization, input validation, rate limits, and secure infrastructure.
Conclusion
WebRTC security starts with strong mandatory transport protection. DTLS-SRTP encrypts audio and video, DTLS protects data channels, and browser secure-context rules help protect device access. Those controls make WebRTC a solid basis for real-time communications, but they do not secure the full application on their own.
Build the rest of the system around that foundation: protect signaling, verify identity, enforce authorization, secure STUN and TURN operations, harden media infrastructure, and define what happens wherever media is decrypted or stored. If you are building a WebRTC streaming application and need help designing a secure, scalable workflow, contact Red5.
