A set of global Nuxt routeRules
that will add appriopriate 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}
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': ['()'],},