Sandro Gauci , Enable Security TURN Server Security Best Practices Published on Feb 25, 2026 in TURN security , server hardening , webrtc security TL;DR The best TURN server security practice is to not run one at all. If you must run one, Isolate it from internal systems, Restrict its relay capabilities, and Update it without fail. This guide covers what to lock down and why, regardless of which TURN implementation you’re running. Do you actually need a TURN server? Before spending time hardening a TURN server, it’s worth asking whether you need one in the first place. As Sean DuBois, creator of the Pion WebRTC library, put it : I really would like to stop seeing people run TURN servers for SFUs! It adds complexity and just adds overhead. And he’s right. If your architecture uses an SFU or MCU, clients connect directly to your media server and ICE with TCP via TLS may be sufficient for NAT traversal without needing a separate TURN relay. TURN is often unnecessary in SFU/MCU-first architectures, but still useful as a fallback in restrictive networks. Every TURN server you deploy is another service to secure, patch, monitor, and defend against abuse. If you can avoid it, do. If you can’t, read on. What this guide covers This is an implementation-agnostic security reference for TURN server deployments. Whether you’re running coturn, eturnal, stunner, or any other TURN server, the security principles here apply universally. We focus on what to secure and why , not the syntax of any particular implementation. Through our penetration testing and vulnerability research at Enable Security, we’ve identified three critical threat categories that require defense in depth: relay abuse, denial of service, and software vulnerabilities. Of course, every deployment is different, and TURN servers are flexible tools, so not every control will apply to every architecture. We’ve tried to be clear about when each recommendation applies and when it doesn’t. Companion guides : For background on TURN security threats and real-world attack examples (including our $3,500 Slack bug bounty and C2 operations research), see TURN Security Threats: A Hacker’s View . For coturn-specific configuration syntax and copy-paste templates, see Securing coturn: Configuration Guide . Heads up Using a third-party TURN provider (e.g. Twilio, Xirsys)? Most of this guide won’t apply to you since the provider handles server hardening. The one thing that does apply is protecting your TURN credential API so that unauthenticated users can’t request credentials from your application. TURN server security checklist Before deploying TURN servers to production, verify each of these security controls: Access control & isolation 1. Isolate TURN server on dedicated network/security group (if applicable - see note) 2. Prevent relay to internal/local IP ranges (if applicable - see note) 3. Restrict relay destinations to known media servers only (if applicable) Protocol hardening 4. Disable unnecessary protocol features (RFC5780, RFC3489) 5. Disable UDP listening (if TCP-only deployment) 6. Disable TCP relay (if UDP-only media) 7. Implement rate limiting (network level at minimum, application level where supported) Operations & maintenance 8. Protect TURN credential APIs 9. Keep server software updated 10. Monitor traffic patterns and security events Warning Items 1-3 are marked “if applicable” because some architectures intentionally relay to internal IP addresses (e.g., SFUs on private networks). If your design requires internal relay, implement selective allow-listing instead of isolation and blanket IP denials. Detailed security controls The following sections explain the rationale and implementation approach for each security control. For coturn-specific configuration syntax, see our coturn configuration guide . 1. Isolate TURN server on dedicated network/security group Why : Prevents attackers from using your TURN server to access adjacent internal systems. Even with access control rules, network isolation provides defense in depth. If the TURN server is compromised or access controls are bypassed, isolation limits what an attacker can reach. When this applies : Most deployments. Exception: architectures where TURN must relay to internal media servers (SFUs, MCUs). In those cases, use restrictive firewall rules to allow only necessary internal destinations. Implementation : Deploy TURN servers in a dedicated security group/network segment with: No access to internal application servers, databases, or management interfaces Outbound rules restricted to public Internet (for external peer relay) If internal relay is required, explicit allow-list rules for specific media server IPs/ports only Separate from WebRTC signaling servers, SFUs, and application infrastructure Verification : From the TURN server, attempts to connect to internal services (SSH, HTTP, databases) should fail due to network-level restrictions. 2. Prevent relay to internal/local IP ranges Why : T...