The visible problem may look like one API or tuning value, but reliability is decided by state ownership, resource bounds, and recovery after failure. TURN accepts public traffic, and anonymous or static accounts can become a free proxy. Realm participates in credential derivation and stays consistent.
TURN is a metered shared relay, not merely an ICE URL. Operate short-lived authorization, allocation concurrency, byte accounting, regional capacity, and abuse response while preserving UDP, TCP, and TLS reachability.
Make the implementation decisions explicit
Start from facts the data and protocol can guarantee, then decide what the interface may promise. Each rule below needs an owner, a bound, and a compatibility policy rather than an oral convention from one review.
- Listen only on required interfaces, enable auth secret, fingerprint, and stale nonce, and deny loopback, link-local, private, and metadata peers.
- Bound every input by size, count, and time, returning a stable actionable error code when a budget is exceeded.
- Treat cleanup as protocol behavior: timers, handles, queues, and temporary data must be safely releasable in every terminal state.
The delivery standard for Hardening coturn Against Anonymous Relay and Unsafe Defaults is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.
Failure paths that are easy to miss
Prioritize faults that silently preserve false facts: the interface looks recovered while a queue, permission, or counter has diverged. The defect often appears only on the next action.
- Arbitrary peer IPs turn the relay into an internal scanner, while public admin or metrics ports expose sessions and control.
- Refresh and network change start two recovery paths, and duplicate side effects look like two genuine user actions.
- An untested fallback receives all traffic during a primary failure and becomes the slower, more expensive bottleneck.
How to verify it before release
Observe both endpoints, persisted records, and operational signals during verification. One button state or one successful response cannot prove the complete loop.
- Probe no auth, expired auth, wrong realm, private peers, port scans, and valid WebRTC, then externally scan to confirm only intended exposure.
- Race refresh, cancel, timeout, and remote completion in one scheduling window; assert one terminal state and one side effect.
- Cover direct, relayed, weak-network, background-tab, and mobile paths; do not rely on averages or one successful screenshot.
The result must be correct, recoverable, and explainable. If any part depends on refreshing the page or an engineer guessing, the protocol loop remains incomplete.