Re: webRTC and Content Security Policy connect-src

On 17/01/2018 11:23, westhawk wrote:
>> On 17 Jan 2018, at 08:53, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
>>
>> Does anyone know of any major webrtc deployment that uses CSP and webrtc today?
> facebook ?
>
> content-security-policy:default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' fbstatic-a.akamaihd.net fbcdn-static-b-a.akamaihd.net *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* *.akamaihd.net wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;
>
(adding the list back)

Then they have a potential security problem as webrtc bypass it and 
makes their use of CSP connect-src irrelevant ;)

Jokes aside, we have only two options for the CSP global swith: make 
webrtc opt-in or opt-out. If we make it opt-in, people using WebRTC and 
CSP will be impacted, if we make it opt-out people using CSP and not 
even caring about webrtc at all would me impacted.

People affected by opt-in less than the ones affected by the opt-put 
ones, although it the impact could be arguably be less critical (service 
disruption vs potential security issue).

My personal vote is to make it opt-in, as webrtc developers are 
(unfortunately) already used to breaking changes between browsers 
versions and IMHO the potential security issue for everyone else is more 
important to be taken care of.

Best regards
Sergio

Received on Wednesday, 17 January 2018 11:49:45 UTC