WebRTC 安全吗？安全与隐私全解析（2026）
内容提要
WebRTC是当前较安全的音视频通话技术：信令强制加密，媒体与数据通道默认加密，禁止明文传输。但媒体服务器会破坏端到端加密，需用SFrame隔离密钥；云端AI功能（转录、摘要、翻译）与端到端加密不兼容。WebRTC仅保障协议层安全，身份、日志、TURN凭证等仍取决于应用自身。它依托开源标准化与浏览器快速更新，安全性优于专有方案，但应用安全仍需开发者自行补齐。
延伸解读
媒体服务器与端到端加密的取舍
WebRTC 默认加密媒体，但一旦引入媒体服务器，加密终点可能落在服务器上。MCU 因需混流必须解密，必然破坏端到端加密；SFU 的朴素实现同样能访问未加密媒体。若要在 SFU 架构下保持端到端加密，需采用 SFrame 让参与者在应用层加解密，并将密钥与服务器隔离。这意味着架构选择直接决定隐私承诺的边界。
云端 AI 功能与端到端加密难以共存
转录、摘要、翻译和云录制等 AI 功能通常运行在云端，需要访问解密后的媒体内容。因此，当开启端到端加密时，这些功能往往被禁用。文章指出，云 AI 功能与端到端加密承诺无法在同一场会议中同时成立。若隐私是首要目标，可考虑设备端 AI 实现，但这取决于具体设备和应用支持路径。
协议安全不等于应用安全
WebRTC 强制加密信令、媒体和数据通道，但身份认证、授权、日志保留、TURN 凭证和房间链接等仍由应用自行负责。文章强调“WebRTC 是安全的，但你的应用不是”，开发者需在协议层安全之上补齐应用层缺口，否则整体服务仍可能存在风险。
浏览器生态带来的安全优势
WebRTC 依托开源标准化和浏览器快速自动更新，安全漏洞能被迅速修复并触达用户。相比专有方案，它接受更广泛的安全审视，且浏览器厂商有更强动力加固安全。但这也意味着安全性部分依赖于浏览器自身的安全实践，开发者需信任并跟进浏览器更新节奏。
Q&A
WebRTC 在协议层面到底安不安全？
WebRTC 在协议层面是安全的。它强制信令使用加密传输（TLS 或 QUIC），所有媒体和数据通道默认加密，禁止明文发送。规范明确要求实现必须支持 SRTP、DTLS 和 DTLS-SRTP，且不得协商 NULL 加密模式或使用 SDES。因此，WebRTC 被认为是目前最安全的 VoIP 技术之一。
WebRTC 的端到端加密在什么情况下会被破坏？
使用 MCU 媒体服务器时，由于服务器需要混流而必须访问媒体，端到端加密会被破坏。朴素的 SFU 实现同样能访问未加密的媒体，但通过 SFrame 让参与者在应用层自行加密并隔离密钥，可以恢复端到端加密。此外，录制、直播、转录和会议摘要等功能也需要访问媒体，因此与端到端加密不相容。
WebRTC 通话中使用 AI 功能（如转录、翻译）会影响隐私吗？
会。转录、摘要、翻译和云录制等 AI 功能大多运行在云端，需要访问解密后的媒体，因此与端到端加密不兼容。开启端到端加密时，这些功能通常会被禁用。如果 AI 运行在用户自有设备上，端到端加密才可能保持。使用这些功能前，需明确其是否开启、在哪里运行、谁能看到媒体。
WebRTC 会泄露我的 IP 地址吗？如何避免？
WebRTC 需要 IP 地址来连接用户，因此会收集并在协商过程中共享。本地 IP 地址曾被视为隐私问题，现已引入 mDNS 支持，使本地网络中的用户仍能被发现而不暴露本地 IP。但公网 IP 地址仍会在点对点通话中共享给对方。若要隐藏公网 IP，可通过 TURN 服务器中继媒体。
使用 WebRTC 是否就意味着我的应用是安全的？
不是。WebRTC 只负责协议层的安全，而应用层的身份认证、授权、日志记录、TURN 凭证和房间链接等仍需开发者自行处理。应用的安全性取决于开发者如何实现这些环节。建议使用 WebRTC 安全清单检查并补齐缺口，避免新手错误。
WebRTC 和 Zoom 等专有方案相比，哪个更安全？
WebRTC 通常更安全。WebRTC 是开源标准化规范，经过广泛审查和浏览器快速更新，安全漏洞能被迅速修复。专有方案外部审视较少，安全投入优先级往往较低，且可能因取巧实现引入漏洞。例如，Zoom 曾因虚假宣传端到端加密被 FTC 指控。但需注意，基于 WebRTC 构建的应用仍可能不安全。
