Headers

A set of global Nuxt routeRules that will add appropriate security headers to your response that will make your application more secure by default. All headers can be overriden by using the module configuration. Check out all the available types here.

It will help you solve this security problem.

To write a custom logic for these global headers follow this pattern:

export default defineNuxtConfig({  security: {    headers: {      xXSSProtection: '1',      contentSecurityPolicy: false    }  }})

Note that setting values for certain headers only overrides the defaults for these particular headers. In order to disable given header, pass false - like the example above shows for contentSecurityPolicy.

To enable per-route configuration, use the routeRules like following:

export default defineNuxtConfig({  routeRules: {    '/custom-route': {      headers: {        'Cross-Origin-Embedder-Policy': 'require-corp'      }    }  }})

When using routeRules, make sure to use the proper HTTP Header names like Cross-Origin-Embedder-Policy instead of crossOriginEmbedderPolicy.

Content-Security-Policy

Content Security Policy (CSP) helps prevent unwanted content from being injected/loaded into your webpages. This can mitigate cross-site scripting (XSS) vulnerabilities, clickjacking, formjacking, malicious frames, unwanted trackers, and other web client-side attacks.

Read more about this header here.

Default value:

contentSecurityPolicy: {  'base-uri': ["'self'"],  'font-src': ["'self'", 'https:', 'data:'],  'form-action': ["'self'"],  'frame-ancestors': ["'self'"],  'img-src': ["'self'", 'data:'],  'object-src': ["'none'"],  'script-src-attr': ["'none'"],  'style-src': ["'self'", 'https:', "'unsafe-inline'"],  'upgrade-insecure-requests': true}

Nonce support

To further increase CSP security, you can use a nonce-based strict csp. This can be configured as follows:

export default defineNuxtConfig({  security: {    nonce: true,    headers: {      contentSecurityPolicy: {        'style-src': [          "'self'",  // fallback value for older browsers, automatically removed if `strict-dynamic` is supported.          "'nonce-{{nonce}}'",        ],         'script-src': [          "'self'",  // fallback value for older browsers, automatically removed if `strict-dynamic` is supported.          "'nonce-{{nonce}}'",          "'strict-dynamic'"        ],        'script-src-attr': [          "'self'",  // fallback value for older browsers, automatically removed if `strict-dynamic` is supported.          "'nonce-{{nonce}}'",          "'strict-dynamic'"        ]      }    }  }})

This will add a nonce attribute to all <script>, <link> and <style> tags in your application. The nonce value is generated per request and is added to the CSP header. This behaviour can be tweaked on a route level by using the routeRules option:

export default defineNuxtConfig({  routeRules: {    '/api/custom-route': {      nonce: false    // do not check nonce for this route (1)    },    '/api/other-route': {      nonce: { mode: 'check' }  // do not generate a new nonce for this route, but check it against the existing one (2)    }  }})

Using nonce in your application code

With the useHead composable

If you are dynamically adding script or link tags in your application using the useHead composable, all nonce values will be automatically added. However, take note that due to a current bug in unjs/unhead, you'll need to add a workaround when using ssr to prevent double loading and executing of your scripts when using nonce.

// workaround unjs/unhead bug for double injection when using nonce// by setting the mode to 'server'// see: https://github.com/unjs/unhead/issues/136 useHead({ script: [{ src: 'https://example.com/script.js' }] }, { mode: 'server' })

Directly inserting tags into DOM

If you are unable or unwilling to use useHead and are inserting directly into the DOM (e.g. document.createElement), you can get the current valid nonce value using the useNonce composable:

const nonce = useNonce()

Cross-Origin-Embedder-Policy

The HTTP Cross-Origin-Embedder-Policy (COEP) response header prevents a document from loading any cross-origin resources that don't explicitly grant the document permission.

Read more about this header here.

Default value:

crossOriginEmbedderPolicy: 'require-corp',

Cross-Origin-Opener-Policy

The HTTP Cross-Origin-Opener-Policy (COOP) response header allows you to ensure a top-level document does not share a browsing context group with cross-origin documents. COOP will process-isolate your document and potential attackers can't access your global object if they were to open it in a popup, preventing a set of cross-origin attacks dubbed XS-Leaks.

Read more about this header here.

Default value:

crossOriginOpenerPolicy: 'same-origin',

Cross-Origin-Resource-Policy

Cross-Origin Resource Policy is a policy set by the Cross-Origin-Resource-Policy HTTP header that lets web sites and applications opt in to protection against certain requests from other origins (such as those issued with elements like <script> and <img>), to mitigate speculative side-channel attacks, like Spectre, as well as Cross-Site Script Inclusion attacks. CORP is an additional layer of protection beyond the default same-origin policy. Cross-Origin Resource Policy complements Cross-Origin Read Blocking (CORB), which is a mechanism to prevent some cross-origin reads by default.

Read more about this header here.

Default value:

crossOriginResourcePolicy: 'same-origin',

Origin-Agent-Cluster

Origin-Agent-Cluster is a new HTTP response header that instructs the browser to prevent synchronous scripting access between same-site cross-origin pages. Browsers may also use Origin-Agent-Cluster as a hint that your origin should get its own, separate resources, such as a dedicated process.

Read more about this header here.

Default value:

originAgentCluster: '?1',

Referrer-Policy

The Referrer-Policy HTTP header controls how much referrer information (sent with the Referer header) should be included with requests. Aside from the HTTP header, you can set this policy in HTML.

Read more about this header here.

Default value:

referrerPolicy: 'no-referrer',

Strict-Transport-Security

The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) informs browsers that the site should only be accessed using HTTPS, and that any future attempts to access it using HTTP should automatically be converted to HTTPS.

Read more about this header here.

Default value:

strictTransportSecurity: 'max-age=15552000; includeSubDomains',

X-Content-Type-Options

The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should be followed and not be changed. The header allows you to avoid MIME type sniffing by saying that the MIME types are deliberately configured.

Read more about this header here.

Default value:

xContentTypeOptions: 'nosniff',

X-DNS-Prefetch-Control

The X-DNS-Prefetch-Control HTTP response header controls DNS prefetching, a feature by which browsers proactively perform domain name resolution on both links that the user may choose to follow as well as URLs for items referenced by the document, including images, CSS, JavaScript, and so forth. This prefetching is performed in the background, so that the DNS is likely to have been resolved by the time the referenced items are needed. This reduces latency when the user clicks a link.

Read more about this header here.

Default value:

xDNSPrefetchControl: 'off',

X-Download-Options

The X-Download-Options HTTP header has only one option: X-Download-Options: noopen. This is for Internet Explorer from version 8 on to instruct the browser not to open a download directly in the browser but instead to provide only the �Save� option. The user has to first save it and then open it in an application.

Read more about this header here.

Default value:

xDownloadOptions: 'noopen',

X-Frame-Options

The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>. Sites can use this to avoid click-jacking attacks, by ensuring that their content is not embedded into other sites.

Read more about this header here.

Default value:

xFrameOptions: 'SAMEORIGIN',

X-Permitted-Cross-Domain-Policies

The X-Permitted-Cross-Domain-Policies header is used to permit cross-domain requests from Flash and PDF documents. In most cases, these permissions are defined in an XML document called crossdomain.xml found in the root directory of the web page. For situations in which the root directory cannot be specified, however, this header can be used to define a desired meta policy. The X-Permitted-Cross-Domain-Policies header should ideally be set as restrictively as possible.

Read more about this header here.

Default value:

xPermittedCrossDomainPolicies: 'none',

X-XSS-Protection

The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. These protections are largely unnecessary in modern browsers when sites implement a strong Content-Security-Policy that disables the use of inline JavaScript ('unsafe-inline').

Read more about this header here.

Default value:

xXSSProtection: '0',

Permissions-Policy

Permissions Policy provides mechanisms for web developers to explicitly declare what functionality can and cannot be used on a web site. You define a set of "policies" that restrict what APIs the site's code can access or modify the browser's default behavior for certain features.

Read more about this header here.

Check out the list of available directives and allowlist here

Default value:

permissionsPolicy: {  'camera': ['()'],  'display-capture': ['()'],  'fullscreen': ['()'],  'geolocation': ['()'],  'microphone': ['()'],},