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 : le trafic WebRTC n'est régi par aucune directive fetch, donc 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 journalise un avertissement de directive non reconnue lorsqu'il la rencontre, et le bug d'implémentation Firefox n'est pas assigné. Voir la section Prise en charge des 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. La directive est tout ou rien : il n'existe aucun moyen 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 peut verrouiller les destinations fetch, XHR et WebSocket, et un script peut quand même ouvrir une connexion pair-à-pair vers un endpoint contrôlé par un attaquant. Ce n'est pas théorique. En 2026, un skimmer réel a utilisé 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, donc cette ligne est sans danger aujourd'hui, et elle fermera la voie d'exfiltration WebRTC dès que les navigateurs livreront la prise en charge. C'est notre recommandation ; aucun organisme de normalisation n'en publie encore, puisque la directive n'a aucune implémentation. Vous pouvez vérifier les points faibles du reste de votre politique avec l'évaluateur CSP.
Reporting
Une fois implémentée, une connexion WebRTC bloquée apparaîtrait sous forme de 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 journalise un avertissement de directive non reconnue, le bug Firefox n'est pas assigné, 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.