webrtc

The webrtc Content Security Policy (CSP) directive controls whether a page may open WebRTC connections. It exists to close a known gap: WebRTC traffic is not governed by any fetch directive, so a script that opens a WebRTC data channel can send data anywhere regardless of the rest of the policy.

Block WebRTC entirely on a page that does not use it:

Content-Security-Policy: webrtc 'block'

Fallback chain

webrtc has no fallback. It is not a fetch directive and default-src does not cover it. When the directive is absent, WebRTC is allowed, which is equivalent to webrtc 'allow'.

Values

webrtc is not a source list. It takes exactly one of two keywords:

Host sources, scheme sources, nonces, and hashes are not valid here. The directive is all or nothing: there is no way to allow WebRTC connections to some peers and block others.

Known bypasses and risks

This directive exists because WebRTC is a policy gap. WebRTC data channels bypass connect-src entirely: a page can lock down fetch, XHR, and WebSocket destinations and still have script open a peer connection to an attacker-controlled endpoint. This is not theoretical. In 2026 a real-world skimmer used a WebRTC data channel to exfiltrate card data past a CSP that restricted connect-src (see the Sansec research in Sources). Until browsers ship webrtc, a policy alone cannot close this exfiltration path.

Recommendation

If your site does not use WebRTC, send the directive now:

Content-Security-Policy: webrtc 'block'

Browsers ignore directives they do not recognize, so this line is harmless today, and it closes the WebRTC exfiltration path the moment browsers ship support. This is our recommendation; no standards body publishes one yet, since the directive has no implementations. You can check the rest of your policy for weak spots with the CSP evaluator.

Reporting

Once implemented, a blocked WebRTC connection would surface as a csp-violation report naming webrtc as the effective directive. No browser emits these reports today.

Browser support

None as of mid-2026. The directive is spec-only: Chrome does not implement it and logs an unrecognized-directive warning, the Firefox bug is unassigned, and Safari has not implemented it either.

See also

• connect-src, which WebRTC traffic bypasses
• Connection-Allowlist, the experimental egress header that blocks WebRTC by default
• Directives index
• CSP keyword values
• Evaluate a policy with the CSP evaluator

Sources

• W3C, Content Security Policy Level 3 editor's draft
• Sansec, WebRTC skimmer research
• Bugzilla, Firefox webrtc directive bug