Cross-Origin-Embedder-Policy

Enabled Prevent a document from loading certain cross-origin resources.

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.

This header should be configured with COOP

Usage

This header is enabled by default but you can change its behavior like following.

export default defineNuxtConfig({
  // Global
  security: {
    headers: {
      crossOriginEmbedderPolicy: <OPTIONS>,
    },
  },

  // Per route
  routeRules: {
    '/custom-route': {
      security: {
        headers: {
          crossOriginEmbedderPolicy: <OPTIONS>,
        },
      },
    }
  }
})

You can also disable this header by crossOriginEmbedderPolicy: false.

Default value

By default, Nuxt Security will set the following value for this header.

Cross-Origin-Embedder-Policy: credentialless

Available values

The crossOriginEmbedderPolicy header can be configured with following values.

crossOriginEmbedderPolicy: 'unsafe-none' | 'require-corp' | 'credentialless' | false;

unsafe-none

Allows the document to fetch cross-origin resources without giving explicit permission through the CORS protocol or the Cross-Origin-Resource-Policy header.

require-corp

In strict mode, this is the default value. A document can only load resources from the same origin, or resources explicitly marked as loadable from another origin. If a cross origin resource supports CORS, the crossorigin attribute or the Cross-Origin-Resource-Policy header must be used to load it without being blocked by COEP.

credentialless

no-cors cross-origin requests are sent without credentials. In particular, it means Cookies are omitted from the request, and ignored from the response. The responses are allowed without an explicit permission via the Cross-Origin-Resource-Policy header. Navigate responses behave similarly as the require-corp mode: They require Cross-Origin-Resource-Policy response header.

Cross-Origin Isolation issues

Setting cross-origin isolation by using the COEP header can sometimes have tricky consequences. This is because the COEP/COOP specification requires both your application and the embedded resource to set corresponding headers properly. If only one of the two parties does not set the headers properly, the frame can be blocked.

As a consequence, in order to avoid being blocked in websites that do not have COEP/COOP headers, some major third-party providers have chosen to not deliver COEP/COOP headers. This in turn prevents you from using COEP in your application! If you want some background, please read the excellent blog note from Stackblitz that explains their decision.

If you encounter this situation, you will be left with a tough dilemna:

• If you choose to apply the require-corp option, the embedded resource will be blocked if it does not deliver the proper headers.
• If you choose to apply the unsafe-none option, the embedded resource will not be cross-origin isolated and therefore might not work properly.

This is the reason why we use the credentialless option by default, which is a reasonable fallback. However even with this setting, you might encounter difficulties.

1. Inspect COEP/COOP issues in your browser's Developer Tools:

• If your console logs tell you that the Embedded Resource is blocked because it does not deliver proper COEP/COOP headers, this means that the third-party resource prevents you from using credentialless. In that case you might have to fallback to unsafe-none.
• If your console logs tell you that some features (e.g. SharedArrayBuffers) are blocked because your application is not cross-origin isolated, your application might still be able to run properly. If it's not the case, you might have to upgrade to require-corp.

2. Have a look at our documentation example code

Our own documentation website includes iframes from Youtube and Stackblitz. Please have a look at our Github source code to see how we set the Nuxt Security options to allow these iframes.