webrtc
La directive CSP webrtc prend allow ou block pour contrôler les connexions WebRTC. Présente dans le brouillon de spec, aucun navigateur ne la livre.
Dernière mise à jour:
La directive webrtc de la politique de sécurité du contenu (CSP) contrôle si une page peut ouvrir des connexions WebRTC. Elle existe pour combler une brèche connue : aucune directive fetch ne régit le trafic WebRTC, si bien qu'un script qui ouvre un data channel WebRTC peut envoyer des données n'importe où, quel que soit le reste de la politique.
Expérimentale, aucune prise en charge navigateur pour le moment
webrtc est définie dans le brouillon d'éditeur de CSP3, mais aucun navigateur ne l'a livrée à la mi-2026. Chrome signale une directive non reconnue quand il la rencontre, et le ticket d'implémentation Firefox n'est attribué à personne. Voir la section Prise en charge par les navigateurs.
Bloquez entièrement WebRTC sur une page qui ne l'utilise pas :
Content-Security-Policy: webrtc 'block'Chaîne de repli
webrtc n'a pas de repli. Ce n'est pas une directive fetch et default-src ne la couvre pas. Lorsque la directive est absente, WebRTC est autorisé, ce qui équivaut à webrtc 'allow'.
Valeurs
webrtc n'est pas une liste de sources. Elle prend exactement un de ces deux mots-clés :
| Valeur | Statut | Description |
|---|---|---|
'allow' | ✅ Bon | Autorise les connexions WebRTC, comme en l'absence de la directive |
'block' | ✅ Bon | Bloque tous les transports WebRTC |
Les sources hôte, les sources de schéma, les nonces et les hashes ne sont pas valides ici. C'est tout ou rien : impossible d'autoriser les connexions WebRTC vers certains pairs et de bloquer les autres.
Contournements et risques connus
Cette directive existe parce que WebRTC est une brèche dans la politique. Les data channels WebRTC contournent entièrement connect-src : une page a beau verrouiller les destinations fetch, XHR et WebSocket, un script peut quand même ouvrir une connexion pair-à-pair vers un endpoint contrôlé par un attaquant. Le risque n'a rien de théorique. En 2026, un skimmer bien réel s'est servi d'un data channel WebRTC pour exfiltrer des données de carte malgré une CSP qui restreignait connect-src (voir la recherche Sansec dans les Sources). Tant que les navigateurs ne livrent pas webrtc, une politique seule ne peut pas fermer cette voie d'exfiltration.
Recommandation
Si votre site n'utilise pas WebRTC, envoyez la directive dès maintenant :
Content-Security-Policy: webrtc 'block'Les navigateurs ignorent les directives qu'ils ne reconnaissent pas : cette ligne est donc sans risque aujourd'hui, et elle fermera la voie d'exfiltration WebRTC dès qu'ils la prendront en charge. C'est notre recommandation ; aucun organisme de normalisation n'en publie encore, faute d'implémentation. Pour le reste de votre politique, l'évaluateur CSP en signale les points faibles.
Reporting
Une fois la directive implémentée, une connexion WebRTC bloquée produirait un rapport csp-violation nommant webrtc comme directive effective. Aucun navigateur n'émet ces rapports aujourd'hui.
Prise en charge par les navigateurs
Aucune à la mi-2026. La directive n'existe que dans la spec : Chrome ne l'implémente pas et signale une directive non reconnue, le ticket Firefox n'est attribué à personne, et Safari ne l'a pas implémentée non plus.
Voir aussi
- connect-src, que le trafic WebRTC contourne
- Connection-Allowlist, le header de sortie expérimental qui bloque WebRTC par défaut
- Index des directives
- Mots-clés CSP
- Évaluer une politique avec l'évaluateur CSP
Sources
report-to
La directive CSP report-to nomme un groupe de reporting déclaré dans Reporting-Endpoints pour recevoir les rapports de violation.
upgrade-insecure-requests
La directive CSP upgrade-insecure-requests réécrit en HTTPS les URL HTTP non sûres de sous-ressource et de navigation avant leur récupération.