Real-time media systems expose TURN relays, media servers and signaling services to the internet; without hardening they can be abused as open relays or knocked offline.
- Restrict TURN servers so they cannot relay to internal or reserved addresses, and stop users from exhausting relay ports.
- Protect media with DTLS-SRTP using approved cipher suites, and check SRTP authentication at the media server.
- Keep media and signaling servers working through malformed packets and floods, with rate limiting.
Each requirement has a level. Level 1 holds the first-layer defenses (about a fifth of the standard), Level 2 adds what OWASP says most applications should strive for, and Level 3 adds defense-in-depth and harder-to-implement controls; meeting a level means meeting every requirement of the levels below it too. Cite a requirement with the version, for example v5.0.0-17.1.1.
V17.1 TURN Server · 2 requirements
V17.1.1 Level 2
Verify that the Traversal Using Relays around NAT (TURN) service only allows access to IP addresses that are not reserved for special purposes (e.g., internal networks, broadcast, loopback). Note that this applies to both IPv4 and IPv6 addresses.
On this site: Secure WebRTC signaling, TURN relays and media servers (guide)
V17.1.2 Level 3
Verify that the Traversal Using Relays around NAT (TURN) service is not susceptible to resource exhaustion when legitimate users attempt to open a large number of ports on the TURN server.
On this site: Secure WebRTC signaling, TURN relays and media servers (guide)
V17.2 Media · 8 requirements
V17.2.1 Level 2
Verify that the key for the Datagram Transport Layer Security (DTLS) certificate is managed and protected based on the documented policy for management of cryptographic keys.
On this site: Secure WebRTC signaling, TURN relays and media servers (guide)
V17.2.2 Level 2
Verify that the media server is configured to use and support approved Datagram Transport Layer Security (DTLS) cipher suites and a secure protection profile for the DTLS Extension for establishing keys for the Secure Real-time Transport Protocol (DTLS-SRTP).
On this site: Secure WebRTC signaling, TURN relays and media servers (guide)
V17.2.3 Level 2
Verify that Secure Real-time Transport Protocol (SRTP) authentication is checked at the media server to prevent Real-time Transport Protocol (RTP) injection attacks from leading to either a Denial of Service condition or audio or video media insertion into media streams.
On this site: Secure WebRTC signaling, TURN relays and media servers (guide)
V17.2.4 Level 2
Verify that the media server is able to continue processing incoming media traffic when encountering malformed Secure Real-time Transport Protocol (SRTP) packets.
On this site: Secure WebRTC signaling, TURN relays and media servers (guide)
V17.2.5 Level 3
Verify that the media server is able to continue processing incoming media traffic during a flood of Secure Real-time Transport Protocol (SRTP) packets from legitimate users.
On this site: Secure WebRTC signaling, TURN relays and media servers (guide)
V17.2.6 Level 3
Verify that the media server is not susceptible to the "ClientHello" Race Condition vulnerability in Datagram Transport Layer Security (DTLS) by checking if the media server is publicly known to be vulnerable or by performing the race condition test.
On this site: Secure WebRTC signaling, TURN relays and media servers (guide)
V17.2.7 Level 3
Verify that any audio or video recording mechanisms associated with the media server are able to continue processing incoming media traffic during a flood of Secure Real-time Transport Protocol (SRTP) packets from legitimate users.
On this site: Secure WebRTC signaling, TURN relays and media servers (guide)
V17.2.8 Level 3
Verify that the Datagram Transport Layer Security (DTLS) certificate is checked against the Session Description Protocol (SDP) fingerprint attribute, terminating the media stream if the check fails, to ensure the authenticity of the media stream.
On this site: Secure WebRTC signaling, TURN relays and media servers (guide)
V17.3 Signaling · 2 requirements
V17.3.1 Level 2
Verify that the signaling server is able to continue processing legitimate incoming signaling messages during a flood attack. This should be achieved by implementing rate limiting at the signaling level.
On this site: Secure WebRTC signaling, TURN relays and media servers (guide)
V17.3.2 Level 2
Verify that the signaling server is able to continue processing legitimate signaling messages when encountering malformed signaling message that could cause a denial of service condition. This could include implementing input validation, safely handling integer overflows, preventing buffer overflows, and employing other robust error-handling techniques.
On this site: Secure WebRTC signaling, TURN relays and media servers (guide)
Requirement IDs, levels and text are from the OWASP Application Security Verification Standard 5.0.0 (copyright © 2008-2025 The OWASP Foundation), unmodified, under the Creative Commons Attribution-ShareAlike 4.0 International License. Imported from release v5.0.0_release (commit 5cf9b03); license.
Guides on this site
Secure WebRTC signaling, TURN relays and media servers
WebRTC encrypts media, but signaling decides whose keys you trust and TURN relays wherever it is allowed. Authorize every signaling message, mint short-lived TURN credentials, deny internal addresses and harden media servers.
Apply security limits to GraphQL, WebSocket and gRPC operations
Carry authorization and resource budgets past the initial HTTP request into resolvers, messages and long-lived streams.
Bound API work, not just request counts
Protect availability and operating cost with limits on input, per-request work, concurrency, queues, and downstream spending.
Operate TLS and certificates: configuration, renewal and verification
Configure a modern TLS profile with hybrid post-quantum key exchange, automate renewal for certificate lifetimes that fall to 47 days, and verify every termination point with a fresh handshake.
Practice
- Repair a real proxy and shared cache · Local project
References
- V17 WebRTC (ASVS 5.0.0 source)
- RFC 3550 - RTP: A Transport Protocol for Real-Time Applications
- RFC 3711 - The Secure Real-time Transport Protocol (SRTP)
- RFC 5764 - Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP))
- RFC 8825 - Overview: Real-Time Protocols for Browser-Based Applications
List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.