> ## Content Index
> Fetch the complete content index at: https://blog.addpipe.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Camera and Microphone Access In Cross Origin Iframes With getUserMedia & Feature Policy
- URL: https://blog.addpipe.com/camera-and-microphone-access-in-cross-oirigin-iframes-with-feature-policy/
- Published: 2020-02-03T14:09:07.000Z
- Updated: 2026-08-19T14:06:05.000Z
- Author: Remus
- Tags: getUserMedia, Technology, #Import 2026-05-22 13:18

If you’re trying to access the camera and microphone with `getUserMedia()` in a **cross origin iframe** on a recent version of Chrome, by default it will fail. 

We’ve encountered this situation several times as users of the [Pipe audio](https://addpipe.com/audio-recorder) and [video recording](https://addpipe.com/video-recorder) platform tried to embed Pipe in [Wix ](https://blog.addpipe.com/how-to-capture-videos-on-your-wix-website-using-pipe-video-recorder/)websites or [Google Site](https://sites.google.com) which use iframes to embed external HTML and JS code.

The cause stems from a series of security & privacy changes that were made to Chrome in 2017 and 2018:

1. [Chrome 60 introduced Feature Policy](https://developers.google.com/web/updates/2018/06/feature-policy) which gave devs a way to control usage of sensitive features inside their websites
2. [Chrome 64 blocked camera and microphone access in cross origin iframes](https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-permissions-in-cross-origin-iframes) by default and required Feature Policy to grant access

Feature Policy allows you to control what sensitive APIs and features are available to the website in the browser. You can control whether or not these features are available through the `Feature-Policy` HTTP header OR by using the `allow` attribute in HTML iframes. 

Sensitive features now include:

- accessing the `camera` and `microphone` through `getUserMedia()`
- the `fullscreen` API
- the `geolocation` API
- accessing the accelerometer or USB devices

You can check [Chrome's source](https://cs.chromium.org/chromium/src/third%5Fparty/blink/renderer/platform/feature%5Fpolicy/feature%5Fpolicy.cc?l=138&rcl=ab90b51c5b60de15054a32b0bd18e4839536a1c9) for an up to date list of features that are under Feature Policy control or [chromestatus.com](https://www.chromestatus.com/features#component%3A%20Blink%3EFeaturePolicy) for a list of policies that are considered for implementation.

Below, we will be focusing on the `allow` attribute in iframes as it relates to camera and microphone access through `getUserMedia()`, for a more detailed overview of Feature Policy check out this [excellent introduction article](https://developers.google.com/web/updates/2018/06/feature-policy).

The `allow` attribute of the `iframe` HTML element enables you to control the sensitive features available within that iframe. The syntax is quite simple, it has the following form:

`<iframe src="" **allow="feature_name allow_list"**></iframe>`

You can specify allow lists for more than one feature by using semicolons:

`<iframe src="" **allow="feature_name allow_list;feature_name allow_list"**></iframe>`

**Thus, to allow camera and microphone access in a cross origin iframe you need to add the following `allow` attribute to your iframe:**

```html
<!--Allow camera and microphone access within the context of this iframe-->
<iframe src="https://example.com" allow="camera;microphone"></iframe>
```

which is equivalent to:

```html
<!--Allow camera and microphone access within the context of this iframe-->
<iframe src="https://example.com" allow="camera *;microphone *"></iframe>
```

The above will allow any page, hosted on any domain to request access to the camera and microphone of the user while loaded through the above iframe. 

To tighten things up you can be more granular about which domains have access to those features as the `allow_list` can have any of the following values:

- `*`: used above, the feature is allowed in top-level browsing contexts and in nested contexts (iframes)
- `'self'`: the feature is allowed in top-level browsing contexts and same-origin nested contexts. The feature is not allowed in cross-origin documents for nested browsing contexts.
- `'none'`: The feature is not allowed at all in top-level and nested browsing contexts.
- `<origin(s)>`: The feature is allowed in specific origin(s), for example `https://my_website.com`

****Start recording on your website today**

Add audio, video, and screen recordings to your website and explore the Pipe Platform for 2 weeks with our 14-day trial.

[Sign Up ](https://dashboard.addpipe.com/signup) 

Without the iframe `allow` attribute above, camera and microphone access won't be allowed in cross origin iframes in browsers that have Feature Policy implemented (see browser support below). If you're [listening for getUserMedia() errors](https://blog.addpipe.com/common-getusermedia-errors/) you'll get a `NotAllowedError` because requests blocked by Feature Policy fail in a similar way as it would if a user had denied a permission prompt.

This is the reason why our own Pipe recorder cannot get camera and microphone access in Chrome when embedded in a website that is built with [Wix](https://www.wix.com/). Wix adds any embedded content through a cross origin iframewhich does not have the required `allow` attribute:

![The Wix iframe code used for embeds lacks Feature Policy's allow attribute](https://blog.addpipe.com/content/images/2020/01/wix-iframe-code-feature-policy.png)

The Wix iframe code used for embeds lacks Feature Policy's allow attribute

Until the release of Feature Policy, the camera and microphone API was already controlled by an older attribute named `allowusermedia`, but this attribute is now deprecated and you should use the new `allow` attribute with the correct values instead, in order to control the access.

If both the old attribute and the new attributes are specified the more restrictive policy will take precedence (in Chrome). For example, the following iframe would not be allowed to request access to the camera, because `allow="camera 'none'"` is more restrictive than `allowusermedia`:

```HTML
<iframe allowusermedia allow="camera 'none'" src="https://example.com"></iframe>
```

It is very important to remember that iframes inherit the feature policy settings of their parent page, this means that if both the page and iframe specify a feature policy list, the more restrictive policy will apply. So, if features in your iframe still do not work, make sure there's not a more restrictive policy imposed through HTTP headers on the parent page.

### Browser support

**Chrome 60** introduced Feature Policy support for both the HTTP header and the `allow` attribute and from our tests, other Chromium based browsers also support the feature like **Opera** and the **new Edge** based on Chromium.

For a full list of browsers that support the feature [see caniuse.com](https://caniuse.com/#feat=feature-policy).

**Chrome 74** also introduced a JavaScript API that allows you to detect which features are allowed by an iframe, page or browser. You can access the API with `frame.featurePolicy` for iframes or `document.featurePolicy` for the page/browser/main document. More details can be found [here](https://developers.google.com/web/updates/2018/06/feature-policy#js).

Further reading:

- [Introduction to Feature Policy](https://developers.google.com/web/updates/2018/06/feature-policy#header)
- [Features disabled by default in Chrome for Cross-Origin iframes](https://dev.chromium.org/Home/chromium-security/deprecating-permissions-in-cross-origin-iframes). These features will have to be specifically enabled in iframes through the Feature Policy.
- [Feature Policy spec](https://w3c.github.io/webappsec-feature-policy/)