Iframe credentialless: Easily embed iframes in COEP environments

Iframe credentialless is enabled by default from Chrome version 110. It solves the most common complaint developers working with Cross-Origin-Embedder-Policy (COEP) have: embedding third-party iframes that do not set COEP.

# Why we need COEP

Some web APIs increase the risk of side-channel attacks such as Spectre. To mitigate that risk, browsers offer an opt-in-based isolated environment called cross-origin isolation, which requires deploying COEP. Cross-origin isolation allows websites to use privileged features including SharedArrayBuffer, performance.measureUserAgentSpecificMemory(), and high-precision timers with better resolution.

To enable cross-origin isolation, websites must send the following HTTP headers:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

COEP:credentialless can also be used as an alternative to require-corp. See the documentation for further details.

# Challenges with enabling COEP

While cross-origin isolation brings webpages better security and the ability to enable powerful features, deploying COEP can be difficult. One of the biggest challenges is that all cross-origin iframes must deploy COEP and CORP. Iframes without those headers will not be loaded by the browser.

# Iframe credentialless to the rescue

We’re introducing <iframe credentialless> to help embed third-party iframes that don’t set COEP. By adding the credentialless attribute to the <iframe> element, the iframe is loaded from a different, empty context. In particular, it is loaded without cookies. This allows for removing the COEP restriction.

Example:

<iframe credentialless src="https://example.com">

This iframe is created in a new ephemeral context and doesn’t have access to any of the cookies associated with the top level website. Instead, it starts with an empty cookie jar. Likewise, storage APIs such as LocalStorage, CacheStorage, IndexedDB, and so on, load and store data in the new ephemeral partition. The partition is scoped to both the current top-level document and the origin of the iframe. All this storage is cleared once the top-level document is unloaded.

Credentialless iframes are not subject to COEP embedding rules. They are still secure: because they are loaded from a new empty context everytime, they should not contain personalized data, which is what attackers are after. If an iframe contains only public data, then it is not valuable to an attacker.

# Demo

You can check out a demo of a credentialless iframe.

# FAQ

# Will this feature be adopted by other browsers?

• Mozilla Request for position: Pending
• Webkit Request for position: No signal
• W3C TAG Request for position: satisfied

# Is an <iframe> nested inside an <iframe credentialless> credentialless?

Yes. It is inherited. Once an iframe is credentialless, that applies to all iframes in the whole subtree even without a credentialless attribute.

# Are pop-ups created from <iframe credentialless> credentialless as well?

Pop-ups are opened as if noopener was set. They are created in a new regular top-level context and are not credentialless. They can’t communicate with the credentialless iframe.

# How to detect the document has been embedded in a credentialless iframe?

window.credentialless is true inside a credentialless iframe and false otherwise. Its value is undefined in a web browser that does not support <iframe credentialless>.

# Resources

• Making your website “cross-origin isolated” using COOP and COEP
• Why you need “cross-origin isolated” for powerful features
• A guide to enable cross-origin isolation
• SharedArrayBuffer updates in Android Chrome 88 and Desktop Chrome 92
• Load cross-origin resources without CORP headers using COEP: credentialless
• IFrame credentialless – Web security | MDN