1

I read about Content Security Policy from: http://developer.chrome.com/extensions/contentSecurityPolicy.html

It is mentioned there that: "If you have a need for some external JavaScript or object resources, you can relax the policy to a limited extent by whitelisting secure origins from which scripts should be accepted"

The example shows that you need to add to your manifest.json this line:

"content_security_policy": "script-src 'self' https://example.com; object-src 'self'"

but if I want not only to support https://example.com, but every web site? btw - is it also possible to include "Evaluated JavaScript": 'unsafe-eval' to that? what should I write instead?

Gorden Gram
  • 921
  • 2
  • 10
  • 14

1 Answers1

3

The page you reference explicitly states, "As man-in-the-middle attacks are both trivial and undetectable over HTTP, those origins will not be accepted." Thus, http: origins are right out. You can whitelist all the secure origins Chrome extensions allow with a protocol-only source: script-src 'self' https:. That's the best you can do inside a Chrome extension: on the web at large, you could whitelist script-src http: https:.

To the other question, 'unsafe-eval' is now permitted in extensions. In previous versions of Chrome it was not allowed, but it seems that Google recently reversed their position on that.

Mike West
  • 5,097
  • 25
  • 26
apsillers
  • 112,806
  • 17
  • 235
  • 239
  • Last question, what about connect-src? I know that chrome allow to make XMLHTTPRequest for every web site in default, but if it will be changed in the future, could I add: 'connect-src *' to the content_security_policy? Is this the right way to write it? – Gorden Gram Dec 12 '12 at 15:00
  • I believe that, in general, all components of the CSP are optional. If you don't want to restrict `connect-src`, just don't include it in your CSP. (Note that Chrome requires extensions to have both `script-src` and `object-src`, but no other CSP directives.) – apsillers Dec 12 '12 at 15:53
  • However, you need to understand that the CSP always makes your web page *less functional* than it would be otherwise, i.e. you cannot use the CSP to *allow* XHR connections that would not be allowed normally. In order to do that in your Chrome extension, just add the appropriate [host permission](http://developer.chrome.com/extensions/xhr.html#requesting-permission) in your manifest. – apsillers Dec 12 '12 at 15:56
  • I asked about connect-src because I want to create an extension but Im afraid that in the future, maybe chrome will change the extension connect-src default. so I want to cover it before.. that's why I asked that if I could write in the extension manifest: "connect-src *" if it will cover it...? (I think that that although you ask host permission it will not cover it if the web host is using CSP and if chrome will also will change the connect-src default, just want to cover it..) thank you! – Gorden Gram Dec 12 '12 at 19:31
  • 1
    Oh, I understand what you mean now. No, the wildcard rules are the same for `connect-src` as they are for `script-src` (and all other sections, too). The odds of Google adding a restrictive `connect-src` seems very low, though, since their extension framework already has a way to contrrol Ajax destinations in the manifest. – apsillers Dec 12 '12 at 19:41
  • Regarding wildcards, if you'd like to allow all HTTPS domains you can do so by whitelisting `https:`: that is, `script-src 'self' https:`. – Mike West Dec 29 '12 at 19:23
  • @MikeWest The content security policy for extensions is even more restrictive; it does not allow host wildcards at all, see http://src.chromium.org/viewvc/chrome/trunk/src/extensions/common/csp_validator_unittest.cc?revision=237426&view=markup#l86 – Rob W Aug 16 '14 at 14:41