3 ms·

It most definitely will, did you read the article? <origin(s)> allows you to define what script origin have access to what features. The example you bring up wh

It most definitely will, did you read the article? <origin(s)> allows you to define what script origin have access to what features. The example you bring up where a script modifies the page to do something would require the 'self' origin, which is definitely not secure. I prefer CSP's language for 'self' being called 'self-insecure', because using the 'self' origin isn't secure. Defining the origins of which scripts have access is really the only secure way to lock out a 3rd party.

Ajedi32 8y ago
Well yes, if you prevent even your own site (self) from accessing a feature then obviously third-party scripts running in the same context as your site won't be able to access it either. Your previous comment however was talking about a situation where your conferencing site needs access to the webcam and mic. In that situation, you _have_ to specify the "self" permission for `camera` and `microphone`, in which case any script embedded in your page (regardless of where you loaded it from) also has access to those features. I see nothing in the original article suggesting otherwise ('origin' refers to the origin of the browsing context, not the origin the script was loaded from). If the article _does_ say otherwise, then the article is wrong. The Feature Policy spec ( https://www.w3.org/TR/CSP3/ https://www.w3.org/TR/CSP3/ ) refers to "browsing contexts", not "the origin a particular script was loaded from".
- move-on-by 8y ago
  I setup a test page for this, and it seems you are right. Test 1: * Feature-Policy "microphone https://example.com" * Javascript that accesses microphone hosted on example.com * Everything loaded and worked as expected Test 2: * Feature-Policy "microphone https://example.com" * Javascript that accesses microphone hosted on 3rd-party.com * Everything loaded and worked - not as expected I definitely didn't understand this new header. I still see how its useful, but not quite as robust as I had expected.

Ajedi32 8y ago

Well yes, if you prevent even your own site (self) from accessing a feature then obviously third-party scripts running in the same context as your site won't be able to access it either. Your previous comment however was talking about a situation where your conferencing site needs access to the webcam and mic. In that situation, you _have_ to specify the "self" permission for `camera` and `microphone`, in which case any script embedded in your page (regardless of where you loaded it from) also has access to those features. I see nothing in the original article suggesting otherwise ('origin' refers to the origin of the browsing context, not the origin the script was loaded from). If the article _does_ say otherwise, then the article is wrong. The Feature Policy spec ( https://www.w3.org/TR/CSP3/ https://www.w3.org/TR/CSP3/ ) refers to "browsing contexts", not "the origin a particular script was loaded from".

move-on-by 8y ago
I setup a test page for this, and it seems you are right. Test 1: * Feature-Policy "microphone https://example.com" * Javascript that accesses microphone hosted on example.com * Everything loaded and worked as expected Test 2: * Feature-Policy "microphone https://example.com" * Javascript that accesses microphone hosted on 3rd-party.com * Everything loaded and worked - not as expected I definitely didn't understand this new header. I still see how its useful, but not quite as robust as I had expected.