🛡 Automatically configure your app to follow OWASP security patterns and principles by using HTTP Headers and Middleware
This version is a significant rewrite of the core engine of Nuxt Security, motivated primarily by the introduction of runtime hooks in PR https://github.com/Baroshem/nuxt-security/pull/298 by @huang-julien and comments thereon by @harlan-zw.
Huge kudos to @vejja for delivering this great functionality 💚
This great addition by Sebastien is well detailed here https://github.com/Baroshem/nuxt-security/pull/429 but as short summary can be seen below.
All security options can now be modified via runtime hooks It is now possible to modify any of the Nuxt Security options, and not solely the headers : any other option such as hidePoweredBy, rateLimiter, is now taken into consideration and applied at route level.
Route rules are now consistently merged The router merging strategy is now the same irrespective of the way the security options are set (inline, global, routeRules, and runtime hooks). Previously, it was a mix of defu, defuReplaceArray, and plain overwriting - leading to confusion on how nested rules would apply (see https://github.com/Baroshem/nuxt-security/issues/430 for instance). We now apply the defuReplaceArray strategy across the board.
Clear scoping of security headers to HTML pages, SWR support We now make a clearer distinction between the scope of Nitro plugins (modifying HTML pages and their headers) and the scope of Server middlewares (functions that apply to all routes). This avoids to overwrite headers of non-HTML assets with irrelevant options, and as a result we are able to support SWR natively.
Route-level support of RateLimiter Thanks to the ability to resolveSecurityRoutes at runtime, we are now able to support route-based definitions for the Rate Limiter. This solves the issue of getting 429 denials for routes where we want to have a higher rate limit. We also take this opportunity to solve the issue of getting 429s when pre-rendering.
This PR introduces a new runtime hook : nuxt-security:routeRules, that allows to modify any security rule on any route. With this hook, the user is now able to apply any strategy for the rule (merge, overwrite, append, etc.).
nitroApp.hooks.hook('nuxt-security:routeRules', async routeRules => {
// any kind of modification of routeRules here, such as :
routeRules['/my-route'] = ...
})
The former nuxt-security:ready & nuxt-security:headers hooks are still supported but we are soft-depecrating them by removing them from the documentation.
This version also soft-deprecates the substitution merging via string syntax feature. This is now rendered unnecessary because the defuReplaceArray strategy is applied consistently everywhere.
We are removing corresponding mentions in the documentation, which were confusing (it only applied to headers, and it only applied in the router merging step but not in the definition step). The feature still exists to maintain backwards compatibility.
Please note that some security options can only be applied globally (removeLoggers, csrf and basicAuth) because they depend on third-party modules. The TypeScript definitions have been updated to remove these 3 options from the properties that can be set at route-level.
We are planning a new release soon with the Nuxt DevTools Tab support 🚀
👉 Changelog compare changes
This version brings several bugfixes and small new features.
Kudos to all contributors! 💚
We are already planning a release 1.3.0 that will include support for rate limiter global and per route as well as protecting api 🚀
👉 Changelog compare changes
import.meta.* propertiesnuxi module add command in installationimport.meta.* properties by @danielroe in https://github.com/Baroshem/nuxt-security/pull/406
nuxi module add command in installation by @danielroe in https://github.com/Baroshem/nuxt-security/pull/410
This version brings several bugfixes and small new features mostly related to XSS Validator.
Kudos to all contributors! 💚
We are already planning a release 1.3.0 that will include support for DevTools 🚀
👉 Changelog compare changes
beforeResponse
beforeResponse by @huang-julien in https://github.com/Baroshem/nuxt-security/pull/370
1.1.0 is the first minor release for a stable 1.0.0 version
The biggest feature of this version is a support for runtime config by @huang-julien ❤️ Take a look at below instructions to understand how to use it in your app.
If you need to change the headers configuration at runtime, it is possible to do it through nuxt-security:headers hook.
This feature is optional, you can enable it with
export default defineNuxtConfig({
modules: ['nuxt-security'],
security: {
runtimeHooks: true
}
})
Within your nitro plugin. You can override the previous configuration of a route with nuxt-security:headers.
export default defineNitroPlugin((nitroApp) => {
nitroApp.hooks.hook('nuxt-security:ready', () => {
nitroApp.hooks.callHook('nuxt-security:headers', '/**' ,{
contentSecurityPolicy: {
"script-src": ["'self'", "'unsafe-inline'"],
},
xFrameOptions: false
})
})
})
And also, huge kudos to all contributors 🎉
We are already planning a release 1.2.0 with additional cool features. Stay tuned! 🚀
👉 Changelog compare changes
1.0.0 is the stable release
After five release candidate versions, we are now ready to present you a stable 1.0.0 release of NuxtSecurity. We have spent a lot of time trying to stabilise the API while constantly improving the security by implementing features like:
From this point I would like to thank @vejja who did an amazing work delivering a lot of functionalities mentioned both above and below. You are a magician! 🚀
And also, huge kudos to all contributors 🎉
We have tried our best not to include significant breaking changes in the recent stable 1.0.0 version but some changes were necessary to improve quality of the module. Don't worry, we have prepared a migration guide with all the changes and how you should approach when migrating your current application to be up to date with 1.0.0 :)
alllowedMethodsRestricterIn the previous version, alllowedMethodsRestricter was an array of HTTP methods or '*' for all methods.
export default defineNuxtConfig({
security: {
allowedMethodsRestricter: ['GET']
}
}
Now it is configured like following:
export default defineNuxtConfig({
security: {
allowedMethodsRestricter: {
methods: ['GET'],
throwError?: true,
}
}
}
This change allows to pass a throwError property that can be useful to return an error response rather than throwing a default Nuxt error.
permissionsPolicyIn the previous version, if you wanted to disable certain API like camera you would do something like this:
export default defineNuxtConfig({
security: {
headers: {
permissionsPolicy: {
'camera': [()]
},
},
},
})
Now it is configured like following:
export default defineNuxtConfig({
security: {
headers: {
permissionsPolicy: {
'camera': [] // This will block usage of camera by this website
},
},
},
})
This change allows to fix an issue of passing several directives mentioned in #194
interval in rateLimiterIn the previous version, if you wanted to set the interval for your rateLimiter you would do something like this:
export default defineNuxtConfig({
security: {
rateLimiter: {
interval: 'hour' | 60000
}
}
})
Now it is configured like following:
export default defineNuxtConfig({
security: {
rateLimiter: {
interval: 60000
}
}
})
This change was required to migrate to an updated rateLimiter that supports modern examples.
In the previous version, nonce could be either an object with a type NonceOptions or false.
export type NonceOptions = {
enabled: boolean;
mode?: 'renew' | 'check';
value?: (() => string);
}
Now it is only a boolean value:
export default defineNuxtConfig({
security: {
nonce: true | false
}
}
This change was necessary to resolve security vulnerability for nonce reported by vejja https://github.com/Baroshem/nuxt-security/pull/257. Read more about the new usage of nonce in this module https://nuxt-security.vercel.app/documentation/headers/csp#nonce
In this version, we have updated ContentSecurityConfiguration by a mile, specifically we have enabled strict CSP by default to spread good security practices.
If you are experiencing some issues with CSP, check out the new documentation about it:
This PR introduces per-route configuration of security headers, via
defineNuxtConfig({
routeRules: {
[some-route]: {
security: {
headers : ...
}
}
}
})
This is the last release candidate version. In the next weeks we are planning to release stable 1.0.0 version :)
👉 Changelog compare changes
credentialless value to Cross-Origin-Embedder-Policy headernonce (#213)nonce option is set to true
interval propertynonce by @trijpstra-fourlights in https://github.com/Baroshem/nuxt-security/pull/213
nonce docs about unsafe-inline during development by @trijpstra-fourlights in https://github.com/Baroshem/nuxt-security/pull/240
false by @dargmuesli in https://github.com/Baroshem/nuxt-security/pull/286
false with boolean by @Mohamed-Kaizen in https://github.com/Baroshem/nuxt-security/pull/284
1.0.0-rc.5 is the next release candidate
This PR introduces per-route configuration of security headers, via
defineNuxtConfig({
routeRules: {
[some-route]: {
security: {
headers : ...
}
}
}
})
This is the last release candidate version. In the next weeks we are planning to release stable 1.0.0 version :)
👉 Changelog compare changes
1.0.0-rc.4 is the next release candidate
We are planning to release one or two more release candidate versions before a stable 1.0.0 version will be released.
This version may include ⚠️ breaking changes but don't worry, we have prepared migration guide for you 😉
In this version, we have updated ContentSecurityConfiguration by a mile, specifically we have enabled strict CSP by default to spread good security practices.
If you are experiencing some issues with CSP, check out the new documentation about it:
👉 Changelog compare changes
1.0.0-rc.3 is the next release candidate
We are planning to release one or two more release candidate versions with bugfixes before a stable 1.0.0 version will be released.
This version includes ⚠️ breaking changes but don't worry, we have prepared migration guide for you 😉
In the previous version, nonce could be either an object with a type NonceOptions or false.
export type NonceOptions = {
enabled: boolean;
mode?: 'renew' | 'check';
value?: (() => string);
}
Now it is only a boolean value:
export default defineNuxtConfig({
security: {
nonce: true | false
}
}
This change was necessary to resolve security vulnerability for nonce reported by vejja https://github.com/Baroshem/nuxt-security/pull/257. Read more about the new usage of nonce in this module https://nuxt-security.vercel.app/documentation/headers/csp#nonce
👉 Changelog compare changes
credentialless value to Cross-Origin-Embedder-Policy headernonce option is set to true
interval property1.0.0-rc.1 is the first release candidate
We are planning to release one or two more release candidate versions with bugfixes before a stable 1.0.0 version will be released.
This version includes ⚠️ breaking changes but don't worry, we have prepared migration guide for you 😉
alllowedMethodsRestricterIn the previous version, alllowedMethodsRestricter was an array of HTTP methods or '*' for all methods.
export default defineNuxtConfig({
security: {
allowedMethodsRestricter: ['GET']
}
}
Now it is configured like following:
export default defineNuxtConfig({
security: {
allowedMethodsRestricter: {
methods: ['GET'],
throwError?: true,
}
}
}
This change allows to pass a throwError property that can be useful to return an error response rather than throwing a default Nuxt error.
permissionsPolicyIn the previous version, if you wanted to disable certain API like camera you would do something like this:
export default defineNuxtConfig({
security: {
headers: {
permissionsPolicy: {
'camera': [()]
},
},
},
})
Now it is configured like following:
export default defineNuxtConfig({
security: {
headers: {
permissionsPolicy: {
'camera': [] // This will block usage of camera by this website
},
},
},
})
This change allows to fix an issue of passing several directives mentioned in #194
interval in rateLimiterIn the previous version, if you wanted to set the interval for your rateLimiter you would do something like this:
export default defineNuxtConfig({
security: {
rateLimiter: {
interval: 'hour' | 60000
}
}
})
Now it is configured like following:
export default defineNuxtConfig({
security: {
rateLimiter: {
interval: 60000
}
}
})
This change was required to migrate to an updated rateLimiter that supports modern examples.
👉 Changelog compare changes
nonce (#213)Full Changelog: https://github.com/Baroshem/nuxt-security/compare/v0.14.2...v0.14.4