feat(core): introduce strict mode

[vejja]

Closes #470

Types of changes

• Bug fix (a non-breaking change which fixes an issue)
• New feature (a non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

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 with default-src: 'none'. In addition, all 'unsafe-inline' values are removed.
2- crossOriginEmbedderPolicy is set to require-corp
3- strictTransportSecurity has the preload flag
4- xFrameOptions is set to DENY

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes (if not applicable, please state why)

[vercel]

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

[vejja]

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

[Baroshem]

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?

[vejja]

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

[hermes85pl]

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?

[hermes85pl]

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 😅

[Baroshem]

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 :)

[vejja]

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 :)

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.

[Baroshem]

Ok, so let's keep it strict then :)

[Baroshem]

Amazing work @vejja !

Feel free to merge this PR and let me know so that I can publish a new version with it :)