+V17 WebRTC
---+V17.1 TURN Server
------+V17.1.1 Verify that the Traversal Using Relays around NAT (TURN) service only allows access to IP addresses …
------+V17.1.2 Verify that the Traversal Using Relays around NAT (TURN) service is not susceptible to resource …
---+V17.2 Media
------+V17.2.1 Verify that the key for the Datagram Transport Layer Security (DTLS) certificate is managed and …
------+V17.2.2 Verify that the media server is configured to use and support approved Datagram Transport Layer …
------+V17.2.3 Verify that Secure Real-time Transport Protocol (SRTP) authentication is checked at the media …
------+V17.2.4 Verify that the media server is able to continue processing incoming media traffic when …
------+V17.2.5 Verify that the media server is able to continue processing incoming media traffic during a flood …
------+V17.2.6 Verify that the media server is not susceptible to the "ClientHello" Race Condition vulnerability …
------+V17.2.7 Verify that any audio or video recording mechanisms associated with the media server are able to …
------+V17.2.8 Verify that the Datagram Transport Layer Security (DTLS) certificate is checked against the Session …
---+V17.3 Signaling
------+V17.3.1 Verify that the signaling server is able to continue processing legitimate incoming signaling …
------+V17.3.2 Verify that the signaling server is able to continue processing legitimate signaling messages when …

V17 WebRTC

Control Objective

Web Real-Time Communication (WebRTC) enables real-time voice, video, and data exchange in modern applications. As adoption increases, securing WebRTC infrastructure becomes critical. This section provides security requirements for stakeholders who develop, host, or integrate WebRTC systems.

The WebRTC market can be broadly categorized into three segments:

  1. Product Developers: Proprietary and open-source vendors that create and supply WebRTC products and solutions. Their focus is on developing robust and secure WebRTC technologies that can be used by others.
  1. Communication Platforms as a Service (CPaaS): Providers that offer APIs, SDKs, and the necessary infrastructure or platforms to enable WebRTC functionalities. CPaaS providers may use products from the first category or develop their own WebRTC software to offer these services.
  1. Service Providers: Organizations that leverage products from product developers or CPaaS providers, or develop their own WebRTC solutions. They create and implement applications for online conferencing, healthcare, e-learning, and other domains where real-time communication is crucial.

The security requirements outlined here are primarily focused on Product Developers, CPaaS, and Service Providers who:

  • Utilize open-source solutions to build their WebRTC applications.
  • Use commercial WebRTC products as part of their infrastructure.
  • Use internally developed WebRTC solutions or integrate various components into a cohesive service offering.

It is important to note that these security requirements do not apply to developers who exclusively use SDKs and APIs provided by CPaaS vendors. For such developers, the CPaaS providers are typically responsible for most of the underlying security concerns within their platforms, and a generic security standard like ASVS may not fully address their needs.

References

For more information, see also:

1. Overzicht

V17.1 TURN Server

This section defines security requirements for systems that operate their own TURN (Traversal Using Relays around NAT) servers. TURN servers assist in relaying media in restrictive network environments but can pose risks if misconfigured. These controls focus on secure address filtering and protection against resource exhaustion.
V17.2 Media

These requirements only apply to systems that host their own WebRTC media servers, such as Selective Forwarding Units (SFUs), Multipoint Control Units (MCUs), recording servers, or gateway servers. Media servers handle and distribute media streams, making their security critical to protect communication between peers. Safeguarding media streams is paramount in WebRTC applications to prevent eavesdropping, tampering, and denial-of-service attacks that could compromise user privacy and communication quality.

In particular, it is necessary to implement protections against flood attacks such as rate limiting, validating timestamps, using synchronized clocks to match real-time intervals, and managing buffers to prevent overflow and maintain proper timing. If packets for a particular media session arrive too quickly, excess packets should be dropped. It is also important to protect the system from malformed packets by implementing input validation, safely handling integer overflows, preventing buffer overflows, and employing other robust error-handling techniques.

Systems that rely solely on peer-to-peer media communication between web browsers, without the involvement of intermediate media servers, are excluded from these specific media-related security requirements.

This section refers to the use of Datagram Transport Layer Security (DTLS) in the context of WebRTC. A requirement related to having a documented policy for the management of cryptographic keys can be found in the "Cryptography" chapter. Information on approved cryptographic methods can be found either in the Cryptography Appendix of the ASVS or in documents such as NIST SP 800‑52 Rev. 2 or BSI TR‑02102‑2 (Version 2025‑01).
V17.3 Signaling

This section defines requirements for systems that operate their own WebRTC signaling servers. Signaling coordinates peer-to-peer communication and must be resilient against attacks that could disrupt session establishment or control.

To ensure secure signaling, systems must handle malformed inputs gracefully and remain available under load.

1.1 Referenties

1.2 Geïdentificeerde eisen

1.3 Gerelateerde regelingen

2. Geïdentificeerde eisen

Eisen

3. Gerelateerde regelingen

Regelingen
  • OWASP -

    EN: Publications of the OWASP Foundation, https://owasp.org/. OWASP® is a registered trademark of the OWASP Foundation, Inc.; GRCA is not affiliated with, nor endorsed by, the OWASP Foundation. Only the versions published by OWASP are authoritative.

    DE: Veröffentlichungen der OWASP Foundation, https://owasp.org/. OWASP® ist eine eingetragene Marke der OWASP Foundation, Inc.; GRCA steht in keiner Verbindung zur OWASP Foundation und wird von ihr nicht unterstützt. Maßgeblich sind allein die von OWASP veröffentlichten Fassungen.