Update helmet to v4 #1347
Update helmet to v4 #1347
Conversation
OtterleyW
force-pushed
the
update-helmet-v4
branch
from
ca28c3c
to
ce10422
Compare
OtterleyW
force-pushed
the
update-helmet-v4
branch
from
ce10422
to
7a63aab
Compare
OtterleyW
force-pushed
the
update-helmet-v4
branch
from
7a63aab
to
c01d93a
Compare
OtterleyW
force-pushed
the
update-helmet-v4
branch
from
c01d93a
to
23263d8
Compare
OtterleyW
force-pushed
the
update-helmet-v4
branch
from
23263d8
to
4c87f97
Compare
|
|
||
| app.use( | ||
| helmet({ | ||
| contentSecurityPolicy: false, |
There was a problem hiding this comment.
@OtterleyW This made me wonder if we should change our default too? I'm afraid that people don't really turn CSP on and that's pretty insecure setup. How understandable the "content blocked" error is if 'block' mode is on by default?
I guess the minimum change would be to just set REACT_APP_CSP to 'block' in .env-template and see that it goes through in config script.
@kpuputti you made this setup originally, do you have an opinion about this?
There was a problem hiding this comment.
Or if that's too much, we could add console warning that "You don't have CSP turned on. You should turn it on before going to production"
There was a problem hiding this comment.
I don't have strong opinions here as I don't really know how much people use CSP and how important they think it is.
One thing to know is that CSP only works when you run the app with a server, the usual yarn run dev doesn't have any CSP features on, so locally you won't see any reports or blocked requests when developing. This makes the .env-template default value quite useless IMO as that file is not used in deployments.
So I'm not sure how much we can help by default. I think report mode by default in production should be fine, as the issues might be difficult to debug and only happen with actual users. A generic CSP warning is also ok, but the reports already show up in the dev tools console.
There was a problem hiding this comment.
@Gnito Do you mean that we should add our own csp as default (meaning that the mode would be report or block) or that we should allow Helmet to add the default csp mode if nothing else is specified (you can see the content here https://github.com/helmetjs/helmet/blob/v4.0.0/middlewares/content-security-policy/index.ts#L48)?
We have default value for csp in app.json if the deploy button is used for deploying to Heroku https://github.com/sharetribe/ftw-daily/blob/master/app.json#L42
Otherwise, we can't affect much on what env variables people use in their prod environments.
There was a problem hiding this comment.
@OtterleyW own default or warning. e.g. stripe.js has some warnings in console log. Not directly related to this piece of code (unless we decide to add console.warn here.
@kpuputti yes, but it would show when ppl use config script or test SSR with ”yarn run dev-server”
There was a problem hiding this comment.
Ah, I see. Indeed by default the server has the CSP disable if the env var is missing. So no reports will be seen in a deployment without the env var.
It sounds like defaulting to "report" or adding a warning makes sense. Warning might be nicer as the reports can fill up the console output.
There was a problem hiding this comment.
And by warning I mean a warning in the frontend console. Having it in the server logs is easily ignored.
There was a problem hiding this comment.
I'm not sure if "report" would generate that much log. At least, we don't get many reports to Sentry. So, I assume that the issue would only be manifested for those who add new scripts/integrations - and that's exactly the correct time to get those reports.
That being said, a warning is probably a safer starting point for those who take updates from upstream :)
There was a problem hiding this comment.
@OtterleyW so, after this discussion. Maybe we should add a warning to src/index.js if REACT_APP_CSP is not set. - And I'm suggesting that you add it to this PR.
There was a problem hiding this comment.
// Edit I didn't see your message before sending mine but you had already basically answered my questions :D
@Gnito Having the warning e.g. in frontend console sounds like a good idea. Do you think it should be included in this PR? And if yes, would adding the warning index.js make sense or is there some other place it would fit better?
OtterleyW
force-pushed
the
update-helmet-v4
branch
from
9121611
to
91d9009
Compare
OtterleyW
force-pushed
the
update-helmet-v4
branch
from
91d9009
to
cc6b8d0
Compare
In Helmet v4 there were some changes to content security policy, see: https://github.com/helmetjs/helmet/wiki/Helmet-4-upgrade-guide#what-changed-in-the-content-security-policy-middleware
In addition to those changes mentioned in the documentation it seems that Helmet is now expecting every directive to be iterable (https://github.com/helmetjs/helmet/blob/v4.0.0/middlewares/content-security-policy/index.ts) We have used also string and boolean values in directives which were causing error after the update and needed to be changed.