The Nuxt Security module is a robust solution for enhancing the security posture of Nuxt 3 applications by automatically configuring HTTP headers and server middleware according to OWASP principles. It provides features such as Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-XSS-Protection, Referrer-Policy, and Permissions-Policy, alongside runtime protections like request size and rate limiters, Cross-Site Scripting (XSS) validation, and Cross-Origin Resource Sharing (CORS) support. The module also offers optional features like basic authentication, allowed HTTP methods control, and CSRF protection. Currently stable at version 2.5.1, `nuxt-security` maintains a rapid release cycle, with frequent hotfixes and minor versions addressing issues, introducing new features, and keeping pace with Nuxt 3 updates. Its primary differentiator is the comprehensive, opinionated, and automatic application of common security best practices without extensive manual configuration. It focuses on server-side protections and integration with Nuxt's SSR/SSG capabilities.
npm install nuxt-securityVerified import paths — ran on the pinned version, not inferred.
This configuration enables various security features for a Nuxt application, including a strict Content Security Policy, XSS protection, rate limiting for all API routes, restricted HTTP methods, XSS validation for form submissions, and basic authentication for an '/admin' section. Remember to set `BASIC_AUTH_USERNAME` and `BASIC_AUTH_PASSWORD` environment variables for basic authentication.
Upgrade your Node.js environment to version 20 or higher using a Node Version Manager (e.g., nvm, fnm) or update your deployment platform's Node.js version.
Upgrade to v2.1.2 or newer. If staying on an older version, explicitly set `removeLoggers: { value: false, route: '/**' }` in your development `nuxt.config.ts`.Develop your CSP iteratively and test thoroughly across all environments (development, production, SSR, SSG). Utilize CSP reporting mechanisms to identify violations, and leverage `nonce` or `hash` attributes for dynamically generated content where 'unsafe-inline' is not desirable.
Test the XSS validator rigorously with various expected user inputs. Consider applying XSS validation only to specific routes (e.g., `/forms/**`) where user-generated content is expected, or disable it entirely for routes where rich content is intentionally permitted and sanitized via other means.
Configure rate limiter `tokens` and `interval` values based on a realistic assessment of expected traffic patterns and client behavior. Utilize the `whiteList` option (introduced in v2.2.0) to exempt known, high-volume clients or internal services from rate limiting.
Run `npx nuxi@latest module add security` or `npm install nuxt-security` to ensure the package is installed. Verify that `'nuxt-security'` is present in the `modules` array within your `nuxt.config.ts`.
Review the `security.headers.contentSecurityPolicy` configuration in `nuxt.config.ts`. Add the problematic URL's domain to the `script-src` directive, or consider using `'unsafe-inline'`/`'unsafe-eval'` (with caution) or `nonce`/`hash` attributes if dynamic inline scripts are necessary.
Check the `security.allowedHTTPMethods` configuration in `nuxt.config.ts` for the route in question. Ensure that the HTTP method used by your client is included in the `value` array. Adjust the configuration or client request method as appropriate.
Increase the `tokens` (maximum requests) or `interval` (time window) values in your `security.rateLimiter` configuration. Alternatively, if the client is legitimate and requires higher limits, consider adding its IP address to the `whiteList` option (if applicable).
Upgrade your local and deployment Node.js version to 20 or higher. Use a Node Version Manager like `nvm` or `fnm` to manage different Node.js versions efficiently.