0

Is there a way to define a content-security-policy header specifying it should trust inline scripts/styles created from a source domain that is already whitelisted?

For instance I have the following header: Content-Security-Policy: script-src https://www.somesite.com

From this site I load https://www.somesite.com/somescript.js which in turn dynamically creates inline styles and scripts without needing a hash or nonce.

Is this possible?

Eladian
  • 958
  • 10
  • 29
  • It’s not possible. Not with current CSP at least. There’s no syntax to express *“trust inline scripts/styles created from a source domain that is already whitelisted”* in CSP. – sideshowbarker Sep 11 '18 at 03:35
  • @sideshowbarker damn that's really harsh :/ So basically if you're running CSP on your website there's no way to have dynamically injected scripts/styles at all without specifying `unsafe-inline` which basically negates the whole purpose in the first place :o That doesn't play well with css-in-js libraries ! – Eladian Sep 11 '18 at 03:38
  • Yup, with CSP *as currently implemented in browsers* at least, there’s no way to have dynamically injected scripts/styles at all without specifying `unsafe-inline`, and yup specifying `unsafe-inline` basically negates the whole purpose of CSP. However, CSP3 adds a new `unsafe-hashes` expression for enabling you to allow particular inline scripts/styles. See https://w3c.github.io/webappsec-csp/#unsafe-hashes-usage. And for more details see https://docs.google.com/document/d/1_nYS4gWYO2Oh8rYDyPglXIKNsgCRVhmjHqWlTAHst7c/edit#heading=h.ue3d7ohicxh3. It hasn’t shipped in any browsers yet, though. – sideshowbarker Sep 11 '18 at 03:58
  • @sideshowbarker Thanks for the links. I don't think they will quite help with what my use case is but might be helpful to someone else. Do you know of any reason why this isn't allowed? It seems to me that if you are loading a script from a whitelisted domain, that script can already do anything it wants in it's own script without the need to inject other scripts into the page. Not allowing whitelisted domains to dynamically inject scripts seems redundant :o – Eladian Sep 11 '18 at 04:29
  • Consider that without `unsafe-inline` specified, CSP doesn’t even allow inline JavaScript to be injected by a script running at the same origin as the document it’s loaded from. So as far as the spec goes — and as far as browser behavior goes — it’s not really an consideration of trusting a particular source/host; instead it’s just that within the script-evaluation and script-execution model that browsers implement, the only way to know that some particular instance of inline JavaScript hasn’t been tampered with is to use an integrity mechanism to check it. Which is what `unsafe-hashes` does. – sideshowbarker Sep 11 '18 at 05:18
  • Yeah you're right. I just thought about it for a minute and realised that even whitelisted domains being allowed to dynamically inject scripts could pose a potential security risk. If you consider that they could source their data externally which could include a – Eladian Sep 11 '18 at 05:46
  • If you could tell the browser that the script wasn't allowed to make any network requests though, that would solve that problem. – Eladian Sep 11 '18 at 06:02
  • If you install a service worker, you can route all requests through the service worker and from the code within that service worker you can programmatically control/allow/disallow particular requests based on domain/hostname. See https://stackoverflow.com/questions/43813770/how-to-intercept-all-http-requests-including-form-submits/43815800#43815800 for a basic example of setting up a service worker to intercept requests – sideshowbarker Sep 11 '18 at 06:18
  • Ahh that's a pretty nifty idea. Ill check that out for added security. Thanks ! :) – Eladian Sep 11 '18 at 11:33

0 Answers0