IFrame credentialless
=====================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

**Non-standard:** This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.

**IFrame credentialless** provides a mechanism for developers to load third-party resources in `<iframe>`s using a new, ephemeral context. It doesn't have access to its regular origin's network, cookies, and storage data. It uses a new context local to the top-level document lifetime. In return, the `Cross-Origin-Embedder-Policy` (COEP) embedding rules can be lifted, so documents with COEP set can embed third-party documents that do not.

The problem
-----------

Various web API features can only be used on sites that opt in to cross-origin isolation — examples include `SharedArrayBuffer` and high-resolution timers. This is because of the risk of such features being exploited in Spectre attacks, where a victim's confidential information can be leaked via a side channel and captured by an attacker.

To opt in to cross-origin isolation, a resource must be served with a `Cross-Origin-Opener-Policy` with a value of `same-origin` (protects your origin from attackers) and `Cross-Origin-Embedder-Policy` with a value of `credentialless` or `require-corp` (protects victims from your origin). The latter prevents a document from loading any credentialled cross-origin resources that don't explicitly grant the document permission using `Cross-Origin-Resource-Policy` or Cross-Origin Resource Sharing.

The key issue limiting the adoption of cross-origin isolation is the fact that `Cross-Origin-Embedder-Policy` is applied recursively — any third-party content loaded into `<iframe>`s in a document with a `Cross-Origin-Embedder-Policy` set must also deploy `Cross-Origin-Embedder-Policy` for the embedding to succeed. This is a problem for developers embedding third-party content in their apps (such as ad-network content) as they generally have no control over it — their only choice up to now has been to wait for the third-party content providers to implement `Cross-Origin-Embedder-Policy`.

This problem can be solved by IFrame credentialless.

The solution — Iframe credentialless
------------------------------------

An `<iframe>` is made credentialless by applying the `credentialless` attribute to it, or setting the equivalent DOM property — `HTMLIFrameElement.credentialless` — to `true`.


```html
<iframe
 src="https://en.wikipedia.org/wiki/Spectre\_(security\_vulnerability)"
 title="Spectre vulnerability Wikipedia page"
 width="960"
 height="600"
 credentialless></iframe>
```


Or:


```html
<iframe width="960" height="600"> </iframe>
```



```js
const iframeElem = document.querySelector("iframe");

iframeElem.credentialless = true;
iframeElem.title = "Spectre vulnerability Wikipedia page";
iframeElem.src =
  "https://en.wikipedia.org/wiki/Spectre\_(security\_vulnerability)";
```


**Note:** The `window.credentialless` property can be queried by a document embedded in an `<iframe>` to test whether it is being run in a credentialless context. A value of `true` means the embedding `<iframe>` is credentialless.

This results in the documents inside the credentialless `<iframe>` being loaded using new, ephemeral contexts — those contexts don't have access to the data associated with their origins; for example cookies and localStorage. The credentialless storage is partitioned out separately with storage keys modified by a nonce ("number used once") value, set once per top-level document. So a cookie set in one credentialless `<iframe>` will be accessible only from other same-origin credentialless `<iframe>`s embedded below the same top-level document.

The nonce is shared for every credentialless iframe that is a descendant of the same top-level document, but it is different for each distinct top-level document the user navigates to, and no longer accessible once the user has navigated away. Credentialless IFrames do not share storage across different pages. Returning to the cookie mentioned above, reloading the document will load the credentialless `<iframe>`s in a different context, so none of the previously-set cookies will be available.

In addition:

* Pop-ups opened by credentialless iframes are opened with `rel="noopener"` set. This prevents OAuth pop-up flows from being used in credentialless iframes.
* Browser autofill or password manager functionality is unavailable in credentialless `<iframes>`.

The result of this is that documents loaded into credentialless `<iframes>` are effectively vanilla or "public" versions, not customized with any user's sensitive information. Since there is no sensitive information available to leak from these documents, they are of no use to would-be attackers, and so the Cross-Origin Embedder Policy requirement is dropped for those IFrames.

Recursive credentialless inside child IFrames
---------------------------------------------

If `credentialless` is set on an `<iframe>` that has child `<iframes>` embedded in the document loaded inside it, those child `<iframe>`s inherit the credentialless setting.

Live demo
---------

Use the https://anonymous-iframe.glitch.me/ demo to see IFrame credentialless in action.

Specifications
--------------

| Specification |
| --- |
| Iframe credentialless  |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Cross-Origin-Opener-Policy`
* `Cross-Origin-Embedder-Policy`
* `Cross-Origin-Resource-Policy`
* Cross-Origin Resource Sharing
* The `<iframe`> `credentialless` attribute
* `HTMLIFrameElement.credentialless`