Closed vejja closed 3 days ago
The latest updates on your projects. Learn more about Vercel for Git ↗︎
Name | Status | Preview | Comments | Updated (UTC) |
---|---|---|---|---|
nuxt-security | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | Jun 27, 2024 5:46pm |
Hi @Baroshem
This is ready now with a full doc update
I'm not too sure about the owaspDefaults
terminology, feel free to suggest otherwise
Cheers
Thanks @vejja for this amazing pull request. May I recommend using option
strict: boolean
That by default is set to false to be comptible and when set to true it will enable more strict options?
But I do wonder, what will happen if user selects strict and then changes the values of the headers manually?
Thanks @vejja for this amazing pull request. May I recommend using option
strict: boolean
Yes, great idea
That by default is set to false to be comptible and when set to true it will enable more strict options?
But I do wonder, what will happen if user selects strict and then changes the values of the headers manually?
This is fine, the manual values will override the strict defaults
How about replacing strict
with mode
or defaults
or something similar (this would be more descriptive and it would read better with other options set next to it in the user config that might override it) and having it as a string to be used as an enum, so that in the future you could introduce other sets of default configuration to choose from while maintaining clean API and not breaking compatibility?
Oh, I see that this was more or less @vejja's original proposal, hence I'm leaning towards that, although proper naming is the key, as usual 😅
The main question is, do we expect to have more presets? also, we could use the keyword preset
and give it a value of strict
or default
. MAybe that would make sense? We could then have it as an enum and be more descriptive :)
The main question is, do we expect to have more presets? also, we could use the keyword
preset
and give it a value ofstrict
ordefault
. MAybe that would make sense? We could then have it as an enum and be more descriptive :)
Personally I would lean towards not having more presets. Maintenance is the issue of course.
On naming issues, I would have loved preset
, but Nitro already uses this terminology and we use it also via nitroPresets
so I did eliminate it mentally.
Ok, so let's keep it strict
then :)
Closes #470
Types of changes
Description
This PR adds a new
strict
option, which can take 2 possible values:false
(default): default settings are chosen to minimize the possibility of breaking the app. These default values are the same as in v1.true
: default settings are chosen to maximize security. These default values will usually require some additional fine-tuning to ensure the app will run smoothly.With the new
strict
mode, the following headers are modified: 1- contentSecurityPolicy blocks everything by default withdefault-src: 'none'
. In addition, all'unsafe-inline'
values are removed. 2- crossOriginEmbedderPolicy is set torequire-corp
3- strictTransportSecurity has thepreload
flag 4- xFrameOptions is set toDENY
Checklist: