feat(core): Security Headers for Pre-rendered Routes

[vejja]

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

With this PR, security headers

• are now available in Hybrid Applications (see security headers with prerendered routes #409)
• are also available in Client-Side Rendered Applications via Nitro presets or hook (see [Feature Request]: expose generated security headers at build time #386)
• are available on non-HTML resources, where relevant (see Support for Security Headers for resources other than HTML #434)

Previously, when a route was pre-rendered via routeRules, the Nuxt application could not deliver the Security Headers. This is because the HTML page is served directly as a pre-built static asset, and we could not intercept the headers in that case to modify them.

This PR proposes a modification of the core engine of Nuxt Security, whereby we now record all pre-rendered pages at build time, and then intercept all requests to verify whether they correspond to a pre-rendered page.

As a consequence of this core upgrade, we now deliver five additional features:

1. For pre-rendered pages in a Nuxt Hybrid application, we are now able to provide CSP by way of headers, in addition to the meta tag. This addresses the issue where some security scanners are complaining about CSP compliance because they do not check the meta tag.
2. More generally, we are now able to provide all security headers for pre-rendered pages. Previously, only CSP could be provided through the meta tag, but now all other policies (e.g. COEP, STS, etc...) can also be delivered via headers for pre-rendered pages in Hybrid Mode.
3. We take this opportunity to also re-activate the cspSsgPresets feature, which had to be deactivated after the upgrade to Nuxt 3.9.3 caused issue "This module cannot be imported in server runtime" error on fresh Nuxt install #348. With this feature, we now generate a headers.json file that is used by Nitro in static presets. For instance, a static website deployed on Vercel or Netlify now has security headers natively on all pages, even without a server runtime !
4. We introduce a new nuxt-security:prerenderedHeaders build-time hook, which allows to further extend the previous feature when there is no Nitro preset available. This hook can be used to manually generate a headers configuration file for any custom static deployment.
5. In addition, we now add some common security headers on non-HTML assets, such as images, .js or .css files, api requests, etc. The following headers are now delivered on all resources: referrerPolicy, strictTransportSecurity, xContentTypeOptions, xDownloadOptions, xFrameOptions, xPermittedCrossDomainPolicies, and xXSSProtection.

Please note that :

• The features 1. and 2. are available under a new ssg: nitroHeaders option (default true). This option is modifiable both globally and at route-level.
• Feature 3. is available under a new ssg: exportToPresets option (default true). This option is only available globally.
• Features 4. and 5. are always available (no option switch).

Closes #386
Closes #409
Closes #434

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	May 8, 2024 0:12am

[Baroshem]

Hi @vejja

Thanks for this amazing PR!

I needed to first release your other PR with SRI fix and it caused the conflicts in this PR. Could you please rebase it? :)

Also, regarding the release of this feature, I would aim for 1.5.0 next week probably if that is ok with you? :)

I will also review it in the upcoming days to give you some feedback.

[vejja]

Hi @vejja

Thanks for this amazing PR!

I needed to first release your other PR with SRI fix and it caused the conflicts in this PR. Could you please rebase it? :)

Also, regarding the release of this feature, I would aim for 1.5.0 next week probably if that is ok with you? :)

I will also review it in the upcoming days to give you some feedback.

1.5.0 sounds good
By the way, I'm also adding a hook for further customization when Nitro presets are not available or when the user wants to create the configuration file himself.
Will update docs and rebase

[vejja]

I'm also closing #434 with this PR
Will update description and notes

[vejja]

@Baroshem
As a side technical note, I am also fixing the issue that popped up with #438 when we released 1.4.0, where we had to duplicate some utils in different folders because runtime code could not access files in the src folder.
I am adding a build.config.ts file that tells unjs/unbuild to make the utils code available at the root.
This allows to put all common code in utils, no duplication required anymore !

[Baroshem]

Two small nitpicks, overall really great work!

[Baroshem]

Amazing work @vejja !

I will merge it to the 2.0.0-rc.1 branch where we can do some additional testing and prepare a big release soon :)