A TURN relay server on a corporate video conferencing platform is being used as a free proxy by an external attacker — making internal HTTP requests across the firewall because the relay accepted unauthenticated long-term credentials. WebRTC security vulnerabilities like this exist in thousands of applications, but most web security professionals have never tested the DTLS/SRTP and STUN/TURN layers that sit outside the HTTP model they know.
This post covers three high-impact WebRTC vulnerability classes from Sandro Gauci’s OWASP research — TURN relay abuse, RTP injection into live media streams, and signaling flood denial of service — with the testing methodology, tooling, and OWASP ASVS requirements to structure your assessments.
Key Takeaways
- You'll learn how WebRTC's built-in security controls (DTLS/SRTP, HTTPS enforcement, ICE authentication) work and why a "secure by design" standard still leaves a massive attack surface that most web and API security professionals completely miss.
- You'll be able to identify and exploit three high-impact WebRTC vulnerability classes — TURN relay abuse, RTP injection, and signaling flood DoS — using publicly available tools and techniques drawn directly from real-world pentest findings.
- Apply a structured approach to WebRTC security testing by leveraging familiar web/API testing methodologies for signaling, specialized tools for TURN and media layers, and the new OWASP ASVS WebRTC requirements chapter to scope and validate your assessments.
WebRTC Architecture and Built-in Security Controls
WebRTC security vulnerabilities begin with understanding what WebRTC actually is and why it was designed the way it was. WebRTC (Web Real-Time Communication) is a browser-native technology that enables voice and video calls and peer-to-peer data exchange directly between browsers and mobile apps — no plugins required. Every major browser ships with a WebRTC stack built in. Its defining characteristic is low latency: media must travel in small UDP packets with millisecond-level timing. This design constraint shapes everything about how WebRTC is architected and secured.
The Three-Layer WebRTC Architecture
A WebRTC application is not just a web app with a video widget bolted on. It has a fundamentally different architecture with three distinct communication layers:
1. Signaling Layer Signaling initiates and tears down the media session. It uses web-native transport — typically HTTP API calls or, more commonly, a persistent WebSocket connection. Signaling carries session metadata: who is calling whom, what codecs are supported, what network addresses will be used. Critically, there is no standard signaling protocol defined in the WebRTC spec. Developers must choose or invent their own — SIP over WebSocket is common, but entirely custom protocols are widespread. This is both an architectural freedom and a recurring security problem.
2. Media Layer The media layer is the actual transfer of voice and video data. It uses the browser’s WebRTC API stack and operates over SRTP (Secure Real-Time Protocol) — encrypted, small UDP packets carrying encoded audio and video. This is fundamentally different from HTTP: there is no request-response model, streams flow continuously in both directions, and the media goes directly between peers or through a media server.
3. NAT Traversal Layer Because direct peer-to-peer communication is blocked by firewalls and NAT in many real-world environments, WebRTC includes a NAT traversal mechanism called ICE (Interactive Connectivity Establishment). ICE relies on:
- STUN servers: help a client discover its public IP address
- TURN servers: act as media relays when direct peer-to-peer or STUN-based traversal fails — tunneling the SRTP stream through the TURN server to the destination
TURN servers are particularly important: in heavily firewalled enterprise environments where UDP is blocked, WebRTC falls back to sending all media through a TURN relay. This makes TURN servers critical infrastructure — and a significant attack surface.
Built-in Security Controls: What WebRTC Gets Right
WebRTC is genuinely one of the more security-conscious open standards in the real-time communications space. Several protections are mandatory at the browser level:
Media Browser Consent Before any WebRTC API can access a microphone or webcam, the browser requires explicit user permission. This is enforced at the browser level — no application code can bypass it.
Enforced HTTPS Browsers enforce HTTPS as a prerequisite for any WebRTC API call. Attempting to use WebRTC APIs over HTTP results in an immediate browser error. This cascades through the entire security model: signaling operates over a secure transport, and since media security depends on secure signaling (the fingerprint exchange below), HTTPS enforcement protects the full chain.
DTLS/SRTP Encryption Audio and video are encrypted using SRTP. The keys are established via DTLS (Datagram Transport Layer Security) — TLS modified to work over UDP. DTLS runs once to establish the master encryption key, then the connection switches to SRTP for the actual media. SRTP’s small UDP packet design is optimized for real-time constraints that TLS was not built to handle.
The DTLS certificates used in WebRTC are typically self-signed, which alarms security engineers on first contact. This is safe by design: the certificate’s fingerprint is communicated through the signaling channel in the SDP, creating a cryptographic binding between the signaling and media layers. You can validate this manually in Wireshark[1]: right-click a DTLS packet, save the certificate, and compare its SHA-256 fingerprint against what appears in the SDP negotiation. A mismatch indicates tampering.
ICE/STUN/TURN Authentication ICE credentials are exchanged over the secure signaling channel. TURN authentication relies on HMAC-SHA1, inherited from STUN’s security model. Credentials are not transmitted in cleartext.
Why “Secure by Design” Is Not the End of the Story
WebRTC is frequently described as a secure standard — and structurally, it is. But as Sandro Gauci puts it: “just because something is said to be secure does not mean it should be ignored.” The security controls above protect the transport layer. They say nothing about how TURN servers are configured, whether media servers validate stream sources, whether custom signaling protocols are implemented correctly, or whether the servers behind the WebRTC stack are hardened. The OWASP ASVS WebRTC chapter[2] codifies exactly what needs to be verified beyond the standard itself.
Actionable Takeaways
- When scoping a WebRTC security assessment, map all three layers explicitly — signaling (WebSocket/HTTP endpoint), media (media server, SRTP stream handling), and NAT traversal (TURN server) — rather than treating the application as a single HTTP target. Each layer has distinct vulnerabilities.
- Validate DTLS certificate fingerprint binding manually on any WebRTC deployment under test: capture the DTLS handshake in Wireshark, extract the certificate, compute its SHA-256 fingerprint, and confirm it matches the value in the SDP signaling. A mismatch is a critical finding indicating possible MitM exposure.
- Do not treat browser-enforced HTTPS and media consent as security controls you need to verify on the server side — they are client-side controls. Your assessment must cover the server-side components (media server, TURN server, signaling server) independently, as browser enforcement provides no protection once an attacker operates outside the browser.
Common Pitfalls
- Treating WebRTC as "just another HTTPS API" and limiting the assessment to the signaling WebSocket. The media and TURN layers have entirely different protocols, tools, and vulnerability classes — skipping them produces an incomplete assessment.
- Flagging self-signed DTLS certificates as a vulnerability without understanding the fingerprint-binding model. In WebRTC, self-signed certificates are expected and safe when the fingerprint is correctly verified against SDP signaling. Raising this as a finding without that context wastes remediation effort and erodes credibility.
WebRTC Attack Surface: Key Differences from Web and API Security
One of the most important shifts when moving into WebRTC security testing is recognizing that the threat model is not an extension of web and API security — it is a parallel domain with its own protocols, communication models, and failure modes. That expertise is valuable for one of WebRTC’s three layers (signaling), but it leaves two full layers completely uncovered.
New Protocols, New Vulnerability Classes
A traditional web application involves a client-server model: the client sends an HTTP request, the server responds. WebRTC applications include all of that, but add:
- DTLS — TLS variant running over UDP, used for key establishment
- SRTP — encrypted real-time media over UDP
- STUN — network address discovery protocol
- TURN — media relay protocol, with its own authentication scheme and access control model
- SDP — Session Description Protocol, carrying codec negotiation and ICE candidates through signaling
- ICE — Interactive Connectivity Establishment, orchestrating the full peer-connection setup
Each of these protocols brings its own attack surface. TURN servers can be abused as SSRF-like proxies. SRTP-handling media servers can be exploited via RTP injection. Signaling channels carrying SDP can be subject to injection, replay, and denial-of-service attacks. None of these map cleanly to OWASP Top 10 HTTP-centric categories.
The Peer-to-Peer Model Changes the Data Flow
In standard web application architecture, all traffic flows through a server you can monitor and control. In WebRTC, media can flow directly between browsers (peer-to-peer) or through a media server — but either way, the media path is separate from the application server path. This means:
- Traffic inspection at the web application layer does not capture media traffic
- A vulnerable media server is reachable independently of the application’s authentication logic
- Attackers who can observe or inject at the network level have opportunities that do not exist in purely HTTP-based applications
Even when a media server is involved, it handles UDP streams at volume, not authenticated HTTP sessions. Its attack surface looks more like a network infrastructure component than a web application.
Availability Is a First-Class Security Property
In web and API security, a slow API that returns responses 500ms late is usually still functionally acceptable. In WebRTC, latency is a hard requirement, not a soft one.
WebRTC stands for Real-Time Communications. The “real-time” constraint means:
- Even small increases in latency make voice calls unusable — audio desynchronizes from video, speakers talk over each other, calls drop
- A WebRTC platform that is “slow” effectively has no value — users switch providers immediately
- Denial of service in WebRTC is not just about uptime; it’s about latency
This means that attacks which would rate as medium severity in a web app context — a resource exhaustion attack that slows response times — are high-severity in WebRTC because they render the service effectively non-functional even if technically “up.”
Three Testing Domains, Three Different Skillsets
The WebRTC attack surface breaks down into three testing domains:
Signaling testing is the most familiar. Signaling operates over WebSocket (or HTTP) and can be intercepted with browser dev tools and interception proxies like OWASP ZAP[3]. The same skills used for web app testing apply — but you’re looking for signaling-specific issues: unauthorized call initiation, missing authentication on session teardown, SDP injection, and resource exhaustion via flooding.
TURN server testing requires dedicated tooling. TURN operates over UDP/TCP using a binary protocol. Use Stunner[4] to test whether the server can be abused to relay to internal addresses, localhost, or cloud metadata services.
Media testing is the most technically demanding. It requires tools that speak SRTP, RTP, and DTLS — Wireshark[1] for capture and analysis, GStreamer for generating RTP streams, and custom scripts for anything beyond standard traffic.
Actionable Takeaways
- When writing up scope for a WebRTC penetration test, explicitly enumerate all three testing domains — signaling endpoints (WebSocket/HTTP), TURN server (host, port, credentials), and media server (UDP ports, media server software and version) — as separate line items. If any domain is out of scope, document it clearly rather than leaving it as an implicit gap.
- Treat any denial-of-service finding against a WebRTC component as one severity level higher than you would for an equivalent web API finding. Latency degradation that does not crash a service is effectively a DoS in real-time communication contexts and should be reported accordingly.
- Before starting a WebRTC assessment, obtain the signaling protocol specification from developers if a custom protocol is in use. Reviewing the spec reveals expected message types, state machine transitions, and authentication requirements that are impossible to infer from traffic inspection alone.
Common Pitfalls
- Scoping a WebRTC application test as "web application + WebSocket" and never testing the TURN server or media server. This leaves the two most WebRTC-specific and least-understood attack surfaces entirely uncovered — which is exactly where novel vulnerabilities are most likely to exist.
- Applying HTTP-centric severity scoring to WebRTC-specific findings without adjusting for real-time availability requirements. A finding that slows signaling by 200ms or corrupts an RTP stream mid-call is functionally a service disruption and warrants high-severity classification in a real-time communications context.
TURN Server Security and Relay Abuse Vulnerabilities
TURN server relay abuse is the most directly analogous WebRTC vulnerability to techniques web and API security professionals already know. If you have ever exploited SSRF, abused an open web proxy, or used a SOCKS proxy to pivot into internal networks, the TURN relay abuse primitive will feel immediately familiar — because it is structurally the same attack.
What a TURN Server Does and Why It Exists
TURN (Traversal Using Relays around NAT) servers are critical infrastructure in most WebRTC deployments. When direct and STUN-based connections fail — common in enterprise environments with UDP-blocking firewalls — WebRTC falls back to routing all media through a TURN server.
The architecture: Client A connects to the TURN server and instructs it to relay traffic to a media server or peer. The TURN server is intentionally designed to accept connection requests and forward traffic to specified destinations. This is exactly what makes it exploitable.
The SSRF Analogy: TURN as a Network Pivot Point
From an attacker’s perspective, a TURN server with insufficient access controls is a network pivot. If you can authenticate to a TURN server — often using credentials found in the application’s JavaScript or obtained through the signaling API — you can instruct it to relay traffic to:
- Internal IP addresses (10.x.x.x, 192.168.x.x, 172.16.x.x ranges)
- Localhost services (127.0.0.1) — databases, admin panels, internal APIs
- Cloud metadata services — notably the AWS Instance Metadata Service at 169.254.169.254, which exposes IAM credentials
- Other internal services that trust requests based on source IP rather than explicit authentication
As Gauci puts it: “Having pentested web proxies, SOCKS proxies and stuff like that where you abuse SSRF where you abuse some server to reach places where you’re not supposed to reach — this seemed like an obvious thing to check out.”
Enable Security built an internal tool — also called Stunner[4] — to exploit this. The tool authenticates to a TURN server, starts a local SOCKS proxy on the attacker’s machine, and routes browser traffic through the relay into the internal network. After testing, they found this vulnerability across multiple client engagements and reported it most notably to Slack, whose public bug bounty program allowed them to publish the report.
PoC: Slack Bug Bounty — TURN Server Relay Abuse to Reach Internal Infrastructure
Enable Security discovered that Slack’s WebRTC TURN server could be abused as a relay proxy to reach internal Slack infrastructure — one of the first public disclosures of TURN server relay abuse against a major production WebRTC deployment.
Proof of Concept Steps:
-
Identify TURN server in Slack’s WebRTC flow. During a Slack voice or video call, WebRTC connection setup provisions TURN credentials. These are accessible by inspecting WebSocket signaling traffic or the JavaScript application context during an active call.
-
Authenticate to Slack’s TURN server. Using Stunner with the provisioned credentials, the researcher authenticated to Slack’s TURN server. The TURN protocol’s HMAC-SHA1 authentication was satisfied by the legitimately issued credentials.
-
Configure Stunner as a SOCKS proxy. Stunner starts a local SOCKS proxy, routing requests through the authenticated TURN relay. The attacker’s browser is configured to use this proxy.
-
Probe internal IP ranges. The attacker uses the browser (via Stunner → Slack’s TURN server) to attempt connections to internal IP address ranges. The TURN relay forwards these requests as if originating from Slack’s internal network.
-
Internal services respond. Certain internal services reached via the relay responded successfully — services that assumed requests from within the network were trustworthy. The bug bounty report was submitted and published, establishing TURN relay abuse as a documented vulnerability class.
PoC: TURN Relay Abuse — 0.0.0.0 Bypass via coturn (CVE)
When the community became aware of TURN relay abuse, coturn[5] implemented a fix: explicitly blocking relay to internal IP address ranges, including 127.0.0.1. Enable Security found a bypass.
The bypass: The coturn deny list checked for 127.0.0.1 but did not account for 0.0.0.0 — which on Linux resolves to the local machine in the same way.
Environment:
- nginx configured to serve
/secretonly to internal IP addresses (403 Forbidden to external requests) - coturn configured with a deny list blocking 127.0.0.1 and RFC-1918 addresses
- Stunner running as a local SOCKS proxy on the attacker’s machine
Attack sequence:
-
Attacker directs browser through Stunner → TURN →
http://127.0.0.1/secret→ TURN server checks deny list, finds 127.0.0.1, returns 403. The block works. -
Attacker changes target to
http://0.0.0.0/secret→ TURN server checks deny list, does not find 0.0.0.0, allows the relay. -
0.0.0.0 resolves to localhost on the TURN server host → nginx receives the request from a local source IP → serves the
/secretcontent with HTTP 200. -
Response travels back through the TURN relay → Stunner → attacker’s browser. The attacker reads the protected resource.
A CVE was assigned and coturn patched it. But the attack pattern persists in older unpatched deployments, custom TURN implementations, and cloud-hosted WebRTC platforms with permissive relay policies.
TURN Server Security Assessment Checklist
- Obtain TURN credentials from the app’s JavaScript or signaling API (they are almost always there)
- Test relay to 127.0.0.1 — should be blocked
- Test relay to 0.0.0.0 — the bypass; test even when 127.0.0.1 is blocked
- Test relay to RFC-1918 ranges (10.x, 172.16.x, 192.168.x)
- Test relay to 169.254.169.254 (AWS metadata; also GCP/Azure equivalents)
- Test relay to external addresses — unauthorized external relay enables bandwidth abuse
- Combine config review with dynamic testing: “By just inspecting the configuration we would have not discovered the bypass”
Actionable Takeaways
- In every WebRTC assessment, extract TURN credentials from the application's signaling API or JavaScript and run relay abuse tests against internal IP ranges (127.0.0.1, 0.0.0.0, 10.x, 169.254.169.254) using Stunner or equivalent tooling. Do not rely on the TURN server's documented configuration to confirm the absence of this vulnerability.
- Test the 0.0.0.0 bypass explicitly even when 127.0.0.1 is blocked. Many TURN server blocklists are incomplete and do not account for all localhost-resolving addresses. Include IPv6 loopback (::1) as well on IPv6-capable deployments.
- When reporting TURN relay abuse, frame it as an SSRF-equivalent finding with internal network access implications, not as a configuration issue. Demonstrating access to 169.254.169.254 and returning IAM credential data will communicate severity more effectively than describing the TURN protocol mechanics.
Common Pitfalls
- Stopping TURN server testing after confirming that 127.0.0.1 is blocked. The 0.0.0.0 bypass — and potentially other representation variants of localhost — can circumvent blocklist-based protections in TURN implementations that have not explicitly accounted for all address forms.
- Treating TURN server security as a configuration review item rather than a dynamic testing requirement. The coturn CVE case demonstrates that a visibly correct configuration can still be exploited; active relay abuse testing against all internal address classes is the only reliable verification method.
Media Security Attacks: RTP Injection and Real-Time Threats
The media layer is the part of WebRTC that most web security professionals never test. It operates below the application logic, speaks binary UDP protocols, and requires different tools than HTTP-based testing. Yet RTP injection — one of the most direct media-layer attacks — requires no exotic tooling to understand or demonstrate, and it has been found repeatedly in real-world WebRTC media server deployments.
RTP vs. SRTP: Why the Distinction Matters
RTP (Real-Time Protocol) is the unencrypted version — continuous streams of small UDP packets carrying encoded audio and video.
SRTP (Secure Real-Time Protocol) is the WebRTC standard — RTP with an encrypted payload and an authentication tag for integrity. The keys come from the DTLS handshake. WebRTC is designed to use SRTP. But not all media server implementations enforce this strictly on every code path.
What Is RTP Injection?
RTP injection is an attack where an attacker sends unauthorized RTP packets to a UDP port that a media server is already using to handle a legitimate call.
The attack flow:
- A legitimate WebRTC call is in progress. The media server receives SRTP streams on specific UDP ports.
- An attacker identifies one of these ports (via SDP negotiation captured in signaling traffic, network observation, or documentation).
- The attacker sends unencrypted RTP packets to that port. Because this is UDP — connectionless, no handshake, no source verification at the transport layer — the media server receives them.
- The media server has to decide what to do with packets that fail SRTP validation.
This attack originates from the VoIP world, where unencrypted RTP was the norm and source validation was often absent. Enable Security found that it “often works in WebRTC media servers” even though those servers are supposed to expect SRTP.
PoC: RTP Injection into Live WebRTC Media Streams
An attacker sends unauthorized unencrypted RTP packets to a UDP port actively handling an SRTP stream; because UDP is connectionless and the media server lacks strict source validation, the server processes or forwards the injected packets, resulting in audio manipulation or denial of service via port spraying.
Proof of Concept Steps:
-
Establish a legitimate call on the target platform to activate media server ports.
-
Extract media server address and port from SDP. During call setup, signaling messages include SDP with ICE candidates listing the media server’s IP and UDP port. Capture using browser dev tools or an interception proxy. Example:
a=candidate:1 1 UDP 2130706431 203.0.113.50 49152 typ host - Generate unencrypted RTP packets using GStreamer[6]:
gst-launch-1.0 audiotestsrc ! rtpL16pay ! udpsink host=203.0.113.50 port=49152Alternatively, craft minimal RTP headers via Python’s
socketlibrary. -
Send injected RTP to the active port during the call and observe three possible outcomes:
Outcome A — Audio manipulation: The media server accepts the unencrypted RTP, encrypts it, and forwards it to call participants. They hear the injected audio (a tone, a voice, white noise) interleaved with or replacing the legitimate call.
Outcome B — Stream corruption: The media server attempts to process the packet, fails, and forwards null or corrupted data. The call goes mute or audio becomes garbled.
Outcome C — Denial of service via port spray: The attacker sends UDP packets across the media server’s full port range (e.g., 49152–65535). Every active call whose assigned port falls within the spray range is affected — calls go mute, degrade, or drop. This is the most consistently reproduced outcome across vulnerable implementations.
- Confirm the finding: Audible artifact in the call (A), call going mute during injection (B), or multiple concurrent calls degrading during port spray (C). Media server logs may show unexpected RTP processing errors.
Why UDP Makes This Possible
The attack is fundamentally enabled by UDP’s connectionless nature: no three-way handshake, no built-in source verification. A properly implemented media server should reject RTP packets that fail SRTP authentication tag validation. Implementations that handle legacy RTP for compatibility, or have incomplete validation on certain code paths, create the injection surface.
Media Server Hardening Requirements
- Strict SRTP enforcement: Reject any packet that fails SRTP authentication tag validation — no fallback to processing as plain RTP
- SSRC binding: Each session should be bound to specific SSRC identifiers negotiated during signaling; packets with unexpected SSRCs should be dropped
- Port isolation: ICE connectivity checks provide source validation that should be enforced
- Rate limiting on UDP: Anomalous packet rates should trigger rate limiting or alerts
Actionable Takeaways
- During a WebRTC assessment, capture the SDP exchanged during signaling to extract the media server's IP address and port range from ICE candidates. Then attempt to send plain RTP packets to those ports during an active call using GStreamer or a minimal Python UDP script. A muted call, audio artifacts, or server errors constitute a confirmed RTP injection vulnerability.
- When reviewing a WebRTC media server's security posture, verify that SRTP authentication tag validation is enforced on all receive code paths — not just the primary path. Compatibility shims or fallback handlers that accept plain RTP on SRTP-configured ports are where this vulnerability typically lives.
- Treat RTP spray across a media server's port range as a DoS finding even if individual injections are rejected. Sending high volumes of UDP to a range of media ports can degrade or terminate multiple concurrent calls and constitutes a denial-of-service vulnerability that should be reported and remediated through rate limiting and ingress filtering.
Common Pitfalls
- Assuming that SRTP enforcement at the WebRTC standard level means the media server implementation correctly validates all incoming packets. The standard mandates SRTP; individual media server implementations may have incomplete validation on edge-case code paths (legacy RTP handling, mixed-mode configurations) that create injection surfaces.
Signaling Security Testing and Practical WebRTC Tooling
The signaling layer is where WebRTC security testing most overlaps with what web and API security professionals already know — and it is the right place to start. Signaling is almost always implemented over WebSocket or HTTP, carries structured messages in formats like JSON or SIP, and can be intercepted, replayed, and fuzzed using familiar tooling.
SIP over WebSocket: The Common Signaling Stack
One of the most widely used WebRTC signaling stacks is SIP (Session Initiation Protocol) over WebSocket. SIP is a mature VoIP signaling protocol with a well-documented vulnerability history. When used over WebSocket for WebRTC it brings a full SIP state machine (REGISTER, INVITE, ACK, BYE, CANCEL, OPTIONS), SIP-specific digest authentication, and a history of resource exhaustion DoS under INVITE flooding.
PoC: SIP over WebSocket Signaling Flood DoS
A high-volume flood of SIP INVITE messages delivered over WebSocket exhausts the media processing component behind the signaling server, preventing call establishment for all users — while the WebSocket layer itself remains responsive, making the attack non-obvious from basic network monitoring.
Target: Enable Security’s purposely vulnerable demo server — a public WebRTC/VoIP test system running SIP over WebSocket signaling with a connected media server backend.
Proof of Concept Steps:
-
Verify target availability. Open browser dev tools, filter for WebSocket traffic. Place a test call — observe SIP INVITE and 200 OK messages. Call connects.
-
Establish a monitoring baseline. Run a SIP PING (SIP OPTIONS message) every second against the signaling server’s WebSocket endpoint to monitor availability in real time.
-
Launch the SIP INVITE flood. Using a distributed attack tool, send a continuous flood of well-formed SIP INVITE messages to the WebSocket endpoint. Each INVITE triggers the signaling server to coordinate with the media server backend — allocating media ports, setting up RTP contexts. Under flood conditions, this resource allocation exhausts the media server’s capacity.
-
Observe impact. Within seconds, the SIP PING monitor reports “timeout detected” — the server is no longer responding to normal SIP traffic.
-
Confirm call establishment failure. Attempt a new call — the WebSocket connection is still alive (the WebSocket server process is fine), but the media server behind it is not responding. Calls hang indefinitely.
Key observation: The WebSocket signaling server stays up. The DoS is against the media server component behind it. This means the attack is invisible to simple TCP port availability checks.
-
Stop the attack. Within seconds, the SIP PING monitor resumes receiving responses. The next call succeeds.
Custom Signaling Protocols: Where History Repeats
Most large-scale WebRTC applications implement custom signaling protocols — proprietary JSON-over-WebSocket message formats, bespoke authentication schemes, and application-specific state machines.
The security problem is consistent: “custom signaling protocols are often also vulnerable, because developers often reinvent the wheel — and with the wheel comes the vulnerabilities.”
Common failure modes:
- Authentication flaws: Missing auth on session teardown, replay of valid tokens, insufficient caller identity validation
- State machine confusion: Sending out-of-order messages to put the server into undefined states
- Resource exhaustion: No rate limiting on session-initiating message types
- SDP injection: Naive parsing of crafted ICE candidates or codec parameters affecting media layer behavior
Do not assume a custom protocol is safer than SIP. It is typically less battle-tested.
The Complete WebRTC Security Testing Toolkit
Signaling layer:
- Browser developer tools — WebSocket filter shows all signaling messages in real time, no proxy configuration required
- OWASP ZAP[3] — for replay, modification, and fuzzing of WebSocket frames; test auth on specific message types, replay invites across sessions, probe state machine transitions
- Custom Python scripts — for flooding, state machine fuzzing, and testing message types not visible in normal traffic
TURN server layer:
- Stunner[4] — operates as a local SOCKS proxy, authenticates to the TURN server using provisioned credentials, routes traffic through the relay; the standard tool for all TURN relay abuse variants
Media layer:
- Wireshark[1] — indispensable; captures DTLS handshakes, SRTP streams, STUN/TURN exchanges; identifies media server UDP ports from ICE candidates; validates certificate fingerprint binding
- GStreamer[6] — generates and sends RTP streams for injection testing without implementing the protocol from scratch
- awesome-rtc-hacking[7] — Enable Security’s curated GitHub repository of WebRTC and VoIP security tools; updated as new tools appear in the community
Security testing playground: Enable Security operates a purposely vulnerable WebRTC/VoIP demo server with multiple intentional security issues — available for free practice and experimentation before applying techniques in actual engagements.
Gray-Box vs. Black-Box Testing
Black-box interception covers obvious message types but often misses rarely-triggered flows — error conditions, admin operations, state reset messages — that may have security gaps. Gray-box access to the signaling protocol specification lets you enumerate the full state machine and test message types that never appear in normal traffic. “If you have a custom signaling protocol, it’s really useful to see the specs — you might miss certain types of messages by just inspecting the traffic.” Request the spec from developers whenever the engagement scope allows it.
OWASP ASVS WebRTC Security Requirements
A major recent development is the integration of WebRTC into the OWASP Application Security Verification Standard (ASVS)[2]. Enable Security contributed a new WebRTC chapter with 13 security requirements:
| Domain | Count | Key requirements |
|---|---|---|
| TURN server | 2 | No relay to RFC-1918/localhost; time-limited credentials |
| Media | 8 | SRTP enforcement; SSRC binding; rate limiting; stream isolation |
| Signaling | 3 | Auth on all message types; rate limiting; SDP input validation |
Use the ASVS WebRTC chapter to structure both assessment scoping and remediation validation. One critical guidance note: proposed requirements must be platform-agnostic, and any requirement that introduces additional latency must consider the real-time trade-off. “Adding any latency will simply make a WebRTC solution less useful.” Frame remediation recommendations in terms of one-time session setup validation, not per-packet overhead.
Actionable Takeaways
- Start every WebRTC signaling assessment by filtering for WebSocket traffic in browser dev tools before opening any proxy. Document all observed message types and their authentication requirements. Then, using an interception proxy, attempt to replay messages from one session in another and send messages out of their expected state machine order. This covers the most common custom signaling protocol vulnerability classes without requiring custom tooling.
- Request the signaling protocol specification from developers at the start of any WebRTC assessment. Cross-reference the spec against observed message types to identify message flows that are never triggered in normal usage but may have missing authentication or validation.
- Adopt the OWASP ASVS WebRTC chapter as the baseline for every WebRTC assessment scope and report. Use its 13 requirements to structure test cases across TURN, media, and signaling layers, and reference specific ASVS requirement IDs in findings to give developers a standardized remediation target.
Common Pitfalls
- Limiting signaling testing to message types observed in a normal user session. WebRTC signaling state machines include error handling messages, session management operations, and administrative message types that may never appear in a standard call flow but are reachable by sending protocol-valid messages directly. Without the protocol spec, these paths remain untested.
- Writing remediation recommendations for media layer findings that add per-packet latency. Such recommendations will be rejected by development teams because they violate WebRTC's real-time latency requirements. Frame media security recommendations in terms of server-side session binding and one-time validation at connection setup rather than per-packet overhead.
Conclusion
WebRTC is embedded in almost every application that does real-time voice, video, or peer-to-peer data — telehealth, enterprise conferencing, gaming, live streaming. It is also almost universally under-tested by the web and API security professionals assessing those applications. The gap is not a mystery: WebRTC’s three-layer architecture (signaling, media, NAT traversal) requires different tools and a different mental model than HTTP-centric assessment work.
The practical path forward is clear. Start with signaling — it’s the most familiar layer and the entry point for state machine attacks and signaling flood DoS. Add TURN server testing — relay abuse is an SSRF-class finding that is often present and rarely checked. Build toward media testing — RTP injection and SRTP validation are where the deepest and most novel vulnerabilities live. Anchor the entire assessment to the OWASP ASVS WebRTC requirements chapter to ensure nothing falls through the gaps.
As Sandro Gauci concludes: “Just because something is said to be secure does not mean it should be ignored. There’s lots to peer through in terms of layers. The attack surface is huge.”
For further reading on related topics, explore application security testing methodologies, VoIP and real-time communication security, and penetration testing frameworks and tooling.
References & Tools
- Wireshark — Network protocol analyzer; used for capturing and inspecting DTLS handshakes, SRTP packet streams, ICE/STUN/TURN exchanges, and validating certificate fingerprint binding in WebRTC deployments. ↩
- OWASP ASVS WebRTC Chapter — New chapter co-authored by Enable Security defining 13 WebRTC-specific security requirements across TURN server, media, and signaling domains; provides a structured baseline for assessments and remediation. ↩
- OWASP ZAP — Open-source interception proxy for capturing, replaying, and modifying WebRTC signaling traffic over WebSocket; the primary signaling layer testing tool for web application security professionals. ↩
- Stunner — Open-source TURN server security testing tool by Christian Mehlmauer; operates as a local SOCKS proxy to route attacker traffic through a target TURN server, enabling relay abuse testing including the 0.0.0.0 bypass. ↩
- coturn — Open-source TURN server implementation; patched the 0.0.0.0 relay abuse bypass (CVE) discovered by Enable Security; reference implementation for understanding TURN relay abuse mitigations. ↩
- GStreamer — Open-source multimedia framework; used to generate and send RTP streams to media server ports for injection testing and PoC construction. ↩
- awesome-rtc-hacking — Enable Security's curated repository of open-source and commercial tools for WebRTC and VoIP security testing; updated as new community tools appear. ↩
Questions from the audience
Related deep dives
Breaking AI Agents: Exploiting Managed Prompt Templates to Take Over Amazon Bedrock Agents
When Passports Execute: Exploiting AI Driven KYC Pipelines | [un]prompted 2026
Agents Exploiting Auth-by-One Errors | [un]prompted 2026
