Purpose of Cross-Origin Embedder Policy Header

The Cross-Origin Embedder Policy (COEP) is a security-focused HTTP response header that prevents a document from loading cross-origin resources that have not explicitly granted permission. By enforcing strict resource-loading rules, COEP protects sensitive data from being leaked through side-channel attacks and allows browsers to safely grant web applications access to powerful, high-performance web platform features.

Mitigating Side-Channel Attacks

Modern processors are vulnerable to speculative execution side-channel attacks, such as Spectre. In a web environment, an attacker can use high-precision timers to measure execution times and infer the contents of memory belonging to another origin loaded in the same process. COEP neutralizes this threat by ensuring that a page cannot load cross-origin assets—such as images, scripts, stylesheets, or iframes—unless those resources explicitly authorize the embedding origin, preventing sensitive external data from entering the process's address space.

Unlocking Cross-Origin Isolation

To protect users, modern browsers restrict access to certain powerful APIs by default. COEP works in tandem with the Cross-Origin Opener Policy (COOP) header to achieve a security state known as "cross-origin isolation." When a site sets both headers, the browser places the page in a dedicated, isolated execution environment.

Achieving cross-origin isolation is required to access advanced browser capabilities, including:

  • SharedArrayBuffer: Enables multi-threaded processing and shared memory across Web Workers.
  • High-precision timers: Provides microsecond-level accuracy via performance.now(), essential for gaming, audio processing, and benchmarking.
  • WebAssembly SIMD and Threads: Accelerates computationally intensive applications running in the browser.
  • performance.measureUserAgentSpecificMemory(): Allows developers to monitor and profile precise memory usage.

Available COEP Directives

The COEP header provides three main configurations:

  • require-corp: The strictest policy. The document can only load resources that explicitly provide a Cross-Origin-Resource-Policy (CORP) header or are loaded using Cross-Origin Resource Sharing (CORS).
  • credentialless: A flexible alternative where cross-origin requests made without explicit CORS or CORP are loaded without credentials (such as cookies or client certificates). This allows embedding legacy cross-origin assets while still achieving isolation.
  • Cross-Origin-Embedder-Policy-Report-Only: A monitoring header that reports potential blocking violations to a specified reporting endpoint without actually breaking or blocking resource loading, ideal for staging environments.

Practical Impact on Web Applications

Implementing COEP requires careful audit of all embedded third-party dependencies. If an external service—such as an analytics tracker, ad network, or media host—does not configure CORS or return a Cross-Origin-Resource-Policy: cross-origin header, the browser will block the resource entirely. Consequently, developers must ensure all external dependencies are properly configured to support explicit cross-origin permissions before enforcing COEP in production.