Content Security Policy 🛂

[StorytellerCZ]

For a while there has been a discussion about Content Security Policy and how to proceed with it.

#9689
#11424
#10704
And more in old feature requests.

I'm now concentrating the discussion here.

I'm proposing that we upgrade the existing packages to use Helmet under the hood and wire up all the additional options so that devs don't have to worry about those things like nonce generation and provide good defaults.

Thoughts?

[krstffr]

Adding my use case/situation for your consideration: I am currently using Helmet, and do not want to allow unsafe-eval (who would?), but would love to be able to use dynamic-imports, but currently can not due to this conflict.

[jankapunkt]

I wonder how others do that to overcome unsafe-eval? I only found polyfills or implementations with eval or function constructor, although I read some use a workaround with blob+nonce but I found no implementation on that.

[cormip]

Using nonce attributes does not permit scripts with unsafe evals to be run. See: https://csplite.com/csp/test152/

[cormip]

Pretty much every security scanner out there will flag script-src: 'unsafe-eval' as a significant security concern:

https://observatory.mozilla.org/

OWASP Zap

This needs to be addressed. It makes it difficult to pitch MeteorJS as a "very secure" platform, when it generates "mediocre" scores from the security scanners.

[paulincai]

https://forums.meteor.com/t/browserpolicy-content-disalloweval-still-gives-unsafe-eval/50336

It can be fixed by ... not using dynamic-imports ... Not a solution I can use though.

[jankapunkt]

How does webpack etc. solve this? They also Support dynamic Imports and I wonder if These Apps require unsafe eval for it as well?

[HemalR]

Is this by any chance something that is fixed in Meteor 3? As @cormip mentioned - the mediocre security scores generated by the inclusion of unsafe-eval can cause issues (and is doing so in our case).

Are there any other workarounds?

[jankapunkt]

From what I have seen there is no fix for dynamic-import without unsafe-eval so far.

[StorytellerCZ]

I think that after Meteor 3.0 this is going to eventually become an increasing issue. I vote for CSP packages and this issue in particularly to be the security improvements focus for 3.1 or 3.2. I personally can help with modernizing the Meteor's CSP packages, but the dynamic-import without unsafe-eval issue is probably beyond me at this time.

[HemalR]

When you say 'CSP packages' are you referring to the browser-policy package? The csp I've implemented uses helmet and that seems to work reasonably well. Although I'm not clued in enough about this and maybe there is merit in having a Meteor specific package for this.

[StorytellerCZ]

Yes, the browser-policy packages. I would like to either integrate Helmet into those packages, or even better with some love figure out an approach to solve the above mentioned issue and do other optimizations specific for Meteor. Honestly, right now I'm handling CSP through the WebApp package easily, so these packages need to add significant value to justify their use (or at the very least make it so that people don't have to think about CSP and get the security that comes when having it properly configured).