5 ms·

Feature Policy won't stop scripts embedded in the same browsing context as your page from accessing everything your own first-party scripts can. It's more for r

Feature Policy won't stop scripts embedded in the same browsing context as your page from accessing everything your own first-party scripts can. It's more for restricting iframes and other sandboxed content embedded in your site. The kind of controls you're describing would difficult to implement, since there are probably dozens of roundabout ways a script could modify the page to trick it into executing code without it being clear that the third-party script is the reason for that code executing. (For example, what if my evil script redefines `console.log`, and then your first-party script calls that?) The very idea of a sandboxed third-party script running in the same context as first-party code is, IMO, contradictory.

move-on-by 8y ago
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.

move-on-by 8y ago

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.