CSP: script-src - HTTP

CSP: script-src
===============

The HTTP `Content-Security-Policy` (CSP) **`script-src`** directive specifies valid sources for JavaScript. This includes not only URLs loaded directly into `<script>` elements, but also things like inline script event handlers (`onclick`) and XSLT stylesheets which can trigger script execution.

|  |  |
| --- | --- |
| CSP version | 1 |
| Directive type | Fetch directive |
| `default-src` fallback |
 Yes. If this directive is absent, the user agent will look for the
 `default-src` directive.
  |

Syntax
------

One or more sources can be allowed for the `script-src` policy:

```http
Content-Security-Policy: script-src <source>;
Content-Security-Policy: script-src <source> <source>;
```

### Sources

`<source>` can be any one of the values listed in CSP Source Values.

Note that this same set of values can be used in all fetch directives (and a number of other directives).

Examples
--------

### Whitelisting resources from trusted domains

Given this CSP header that only allows scripts from `https://example.com`:

```http
Content-Security-Policy: script-src https://example.com/
```

the following script is blocked and won't be loaded or executed:

```html
<script src="https://not-example.com/js/library.js"></script>
```

Note that inline event handlers are blocked as well:

```html
<button id="btn" onclick="doSomething()"></button>
```

You should replace them with `addEventListener` calls:

```js
document.getElementById("btn").addEventListener("click", doSomething);
```

 If you cannot replace inline event handlers, you can use the `'unsafe-hashes'` source expression to allow them.
 See Unsafe hashes for more information.

### Whitelisting external scripts using hashes

 Allowing trusted domains, as shown in the section above, is a broad-brushed approach for specifying the locations from which code can safely be loaded.
 This is a pragmatic approach, in particular when your site uses many resources and you have confidence that the trusted site will not be compromised.

 An alternative method is to specify allowed scripts using file hashes.
 Using this approach an external file in a `<script>` element can only be loaded and executed if all the valid hash values in its `integrity` attribute match the allowed values in the CSP header.
 The Subresource integrity feature additionally checks that the downloaded file has the indicated hash value, and therefore has not been modified.
 This is safer than trusting a domain, because files will only be used if they are unmodified, even if loaded from a compromised site.
 It is however more granular, and requires that hash values are updated in CSP and script elements whenever the associated scripts are changed.

 The CSP header below demonstrates the approach.
 It allows scripts for which the SHA384 hash is `oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC` or the SHA256 hash is `fictional_value`.

```http
Content-Security-Policy: script-src 'sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC' 'sha256-fictional\_value'
```

The `example-framework.js` script below should load because the hash value in its `integrity` attribute is also present in the CSP (provided the file actually does have that hash once downloaded!)

```html
<script
 src="https://example.com/example-framework.js"
 integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
 crossorigin="anonymous"></script>
```

 The `integrity` attribute can have multiple values, each providing a hash for the file calculated using a different algorithm.
 In order for an external script to be loaded, CSP requires that *all* valid hash values in the attribute must also be in the CSP `script-src` declaration.
 Therefore the script below would not load, because the second hash is not present in the CSP header above.

```html
<script
 src="https://example.com/example-framework.js"
 integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC sha256-not-in-csp"
 crossorigin="anonymous"></script>
```

 This rule only applies to *valid* hash values.
 Values that are not recognized as hashes by the browser are ignored, so the following script should load:

```html
<script
 src="https://example.com/example-framework.js"
 integrity="invalid-or-unsupported-hash sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
 crossorigin="anonymous"></script>
```

Subresource integrity contains more information about calculating hashes and using the `integrity` attribute.

### Unsafe inline script

**Note:**
 Disallowing inline styles and inline scripts is one of the biggest security wins CSP provides.
 If you absolutely have to use them, there are a few mechanisms that will allow them.
 Hashes apply to inline scripts and styles, but not event handlers.
 See Unsafe hashes for more information.

 To allow inline scripts and styles, `'unsafe-inline'`, a nonce-source or a hash-source that matches the inline block can be specified.
 The following Content Security Policy will allow all inline `<script>` elements:

```http
Content-Security-Policy: script-src 'unsafe-inline';
```

The following `<script>` element will be allowed by the policy:

```html
<script>
 const inline = 1;
 // …
</script>
```

 Allowing all inline scripts is considered a security risk, so it's recommended to use a nonce-source or a hash-source instead.
 To allow inline scripts and styles with a nonce-source, you need to generate a random nonce value (using a cryptographically secure random token generator) and include it in the policy.
 It is important to note, this nonce value needs to be dynamically generated as it has to be unique for each HTTP request:

```http
Content-Security-Policy: script-src 'nonce-2726c7f26c'
```

Then, you need to include the same nonce in the `<script>` element:

```html
<script nonce="2726c7f26c">
 const inline = 1;
 // …
</script>
```

Alternatively, you can create hashes from your inline scripts. CSP supports sha256, sha384 and sha512.

```http
Content-Security-Policy: script-src 'sha256-B2yPHKaXnvFWtRChIbabYmUBFZdVfKKXHbWtWidDVF8='
```

When generating the hash, don't include the `<script>` tags and note that capitalization and whitespace matter, including leading or trailing whitespace.

```html
<script>
 const inline = 1;
</script>
```

### Unsafe hashes

Policies for inline resources with hashes like `script-src 'sha256-{HASHED_INLINE_SCRIPT}'` allow scripts and styles by their hash, but not event handlers:

```html
<!-- Allowed by CSP: script-src 'sha256-{HASHED\_INLINE\_SCRIPT}' -->
<script>
 const inline = 1;
</script>

<!-- CSP: script-src 'sha256-{HASHED\_EVENT\_HANDLER}'
 will not allow this event handler -->
<button onclick="myScript()">Submit</button>
```

 Instead of allowing `'unsafe-inline'`, you can use the `'unsafe-hashes'` source expression if code can't be updated to equivalent `addEventListener` calls.
 Given a HTML page that includes the following inline event handler:

```html
<!-- I want to use addEventListener, but I can't :( -->
<button onclick="myScript()">Submit</button>
```

The following CSP header will allow the script to execute:

```http
Content-Security-Policy: script-src 'unsafe-hashes' 'sha256-{HASHED\_EVENT\_HANDLER}'
```

### Unsafe eval expressions

 The `'unsafe-eval'` source expression controls several script execution methods that create code from strings.
 If a page has a CSP header and `'unsafe-eval'` isn't specified with the `script-src` directive, the following methods are blocked and won't have any effect:

* `eval()`
* `Function()`
* When passing a string literal like to methods like: `setTimeout("alert(\"Hello World!\");", 500);`
    + `setTimeout()`
    + `setInterval()`
    + `window.setImmediate`
* `window.execScript()`
Non-standard
 (IE < 11 only)
### Unsafe WebAssembly execution

 The `'wasm-unsafe-eval'` source expression controls WebAssembly execution.
 If a page has a CSP header and `'wasm-unsafe-eval'` isn't specified in the `script-src` directive, WebAssembly is blocked from loading and executing on the page.

 The `'wasm-unsafe-eval'` source expression is more specific than `'unsafe-eval'` which permits both compilation (and instantiation) of WebAssembly and, for example, the use of the `eval` operation in JavaScript.
 If the `'unsafe-eval'` source keyword is used, then this overrides any occurrence of `'wasm-unsafe-eval'` in the CSP policy.

```http
Content-Security-Policy: script-src 'wasm-unsafe-eval'
```

### strict-dynamic

The `'strict-dynamic'` source expression specifies that the trust explicitly given to a script present in the markup, by accompanying it with a nonce or a hash, shall be propagated to all the scripts loaded by that root script. At the same time, any allowlist or source expressions such as `'self'` or `'unsafe-inline'` will be ignored.

For example, a policy such as `script-src 'strict-dynamic' 'nonce-R4nd0m' https://allowlisted.example.com/` would allow loading of a root script with `<script nonce="R4nd0m" src="https://example.com/loader.js">` and propagate that trust to any script loaded by `loader.js`, but disallow loading scripts from `https://allowlisted.example.com/` unless accompanied by a nonce or loaded from a trusted script.

```http
Content-Security-Policy: script-src 'strict-dynamic' 'nonce-someNonce'
```

Or:

```http
Content-Security-Policy: script-src 'strict-dynamic' 'sha256-base64EncodedHash'
```

 It is possible to deploy `strict-dynamic` in a backwards compatible way, without requiring user-agent sniffing.
 The policy:

```http
Content-Security-Policy: script-src 'unsafe-inline' https: 'nonce-abcdefg' 'strict-dynamic'
```

will act like `'unsafe-inline' https:` in browsers that support CSP1, `https: 'nonce-abcdefg'` in browsers that support CSP2, and `'nonce-abcdefg' 'strict-dynamic'` in browsers that support CSP3.

### Allowing speculation rules

To include speculation rules in scripts (see also `<script type="speculationrules">`), you need to use the `script-src` directive along with the `'inline-speculation-rules'` source and a hash- or nonce-source. For example:

```http
Content-Security-Policy: script-src 'inline-speculation-rules' 'sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC'
```

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

| Specification |
| --- |
| Content Security Policy Level 3 # directive-script-src |

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

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

See also
--------

* `Content-Security-Policy`
* `Sources`
* `<script>`
* `script-src-elem`
* `script-src-attr`


CSP: base-uri - HTTP

CSP: base-uri
=============

The HTTP `Content-Security-Policy` **`base-uri`** directive restricts the URLs which can be used in a document's `<base>` element. If this value is absent, then any URI is allowed. If this directive is absent, the user agent will use the value in the `<base>` element.

|  |  |
| --- | --- |
| CSP version | 2 |
| Directive type | Document directive |
| `default-src` fallback | No. Not setting this allows any URL. |

Syntax
------

One or more *sources* can be allowed for the base-uri policy:

```http
Content-Security-Policy: base-uri <source>;
Content-Security-Policy: base-uri <source> <source>;
```

### Sources

This directive uses most of the same source values for arguments as other CSP directives: CSP Source Values.

Note however that some of the values don't make sense for `base-uri`, such as the keywords `'unsafe-inline'` and `'strict-dynamic'`.

Examples
--------

### Meta tag configuration

```html
<meta http-equiv="Content-Security-Policy" content="base-uri 'self'" />
```

### Apache configuration

```apacheconf
<IfModule mod\_headers.c>
Header set Content-Security-Policy "base-uri 'self'";
</IfModule>
```

### Nginx configuration

```nginx
add_header Content-Security-Policy "base-uri 'self';"
```

### Violation case

Since your domain isn't `example.com`, a `<base>` element with its `href` set to `https://example.com` will result in a CSP violation.

```html
<meta http-equiv="Content-Security-Policy" content="base-uri 'self'" />
<base href="https://example.com/" />

<!--
// Error: Refused to set the document's base URI to 'https://example.com/'
// because it violates the following Content Security Policy
// directive: "base-uri 'self'"
-->
```

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

| Specification |
| --- |
| Content Security Policy Level 3 # directive-base-uri |

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

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

See also
--------

* `Content-Security-Policy`
* `<base>`
* `Node.baseURI`


CSP: sandbox - HTTP

CSP: sandbox
============

 The HTTP `Content-Security-Policy` (CSP)
 **`sandbox`** directive enables a sandbox for the requested
 resource similar to the `<iframe>` `sandbox`
 attribute. It applies restrictions to a page's actions including preventing popups,
 preventing the execution of plugins and scripts, and enforcing a same-origin policy.

|  |  |
| --- | --- |
| CSP version | 1.1 / 2 |
| Directive type | Document directive |
|
 This directive is not supported in the `<meta>`
 element or by the
 `Content-Security-policy-Report-Only`
 header field.
  |

Syntax
------

```http
Content-Security-Policy: sandbox;
Content-Security-Policy: sandbox <value>;
```

where `<value>` can optionally be one of the following values:

`allow-downloads`

Allows downloading files through an `<a>` or `<area>` element with the download attribute, as well as through the navigation that leads to a download of a file. This works regardless of whether the user clicked on the link, or JS code initiated it without user interaction.

`allow-downloads-without-user-activation`
Experimental

Allows for downloads to occur without a gesture from the user.

`allow-forms`

Allows the page to submit forms. If this keyword is not used, form will be displayed as normal, but submitting it will not trigger input validation, sending data to a web server or closing a dialog.

`allow-modals`

Allows the page to open modal windows by `Window.alert()`, `Window.confirm()`, `Window.print()` and `Window.prompt()`, while opening a `<dialog>` is allowed regardless of this keyword. It also allows the page to receive `BeforeUnloadEvent` event.

`allow-orientation-lock`

Lets the resource lock the screen orientation.

`allow-pointer-lock`

Allows the page to use the Pointer Lock API.

`allow-popups`

Allows popups (like from `Window.open()`, `target="_blank"`, `Window.showModalDialog()`). If this keyword is not used, that functionality will silently fail.

`allow-popups-to-escape-sandbox`

Allows a sandboxed document to open new windows without forcing the sandboxing flags upon them. This will allow, for example, a third-party advertisement to be safely sandboxed without forcing the same restrictions upon the page the ad links to.

`allow-presentation`

Allows embedders to have control over whether an iframe can start a presentation session.

`allow-same-origin`

If this token is not used, the resource is treated as being from a special origin that always fails the same-origin policy (potentially preventing access to data storage/cookies and some JavaScript APIs).

`allow-scripts`

Allows the page to run scripts (but not create pop-up windows). If this keyword is not used, this operation is not allowed.

`allow-storage-access-by-user-activation`
Experimental

Lets the resource request access to the parent's storage capabilities with the Storage Access API.

`allow-top-navigation`

Lets the resource navigate the top-level browsing context (the one named `_top`).

`allow-top-navigation-by-user-activation`

Lets the resource navigate the top-level browsing context, but only if initiated by a user gesture.

`allow-top-navigation-to-custom-protocols`

Allows navigations to non-`http` protocols built into browser or registered by a website. This feature is also activated by `allow-popups` or `allow-top-navigation` keyword.

Examples
--------

```http
Content-Security-Policy: sandbox allow-scripts;
```

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

| Specification |
| --- |
| Content Security Policy Level 3 # directive-sandbox |

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

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

See also
--------

* `Content-Security-Policy`
* `sandbox` attribute on `<iframe>`
 elements


CSP: script-src-elem - HTTP

CSP: script-src-elem
====================

The HTTP `Content-Security-Policy` (CSP) **`script-src-elem`** directive specifies valid sources for JavaScript `<script>` elements.

 This directive only specifies valid sources in `<script>` elements (both script requests and blocks).
 It does not apply to other JavaScript sources that can trigger script execution, such as inline script event handlers (`onclick`), script execution methods gated on the "unsafe-eval" check, and XSLT stylesheets.
 (Valid sources can be specified for all JavaScript script sources using `script-src`, or just for inline script handlers using `script-src-attr`.)

|  |  |
| --- | --- |
| CSP version | 3 |
| Directive type | Fetch directive |
| `default-src` fallback |
 Yes.
 If this directive is absent, the user agent will look for the `script-src` directive, and if both of them are absent, fall back to `default-src` directive.
  |

Syntax
------

One or more sources can be allowed for the `script-src-elem` policy:

```http
Content-Security-Policy: script-src-elem <source>;
Content-Security-Policy: script-src-elem <source> <source>;
```

`script-src-elem` can be used in conjunction with `script-src`:

```http
Content-Security-Policy: script-src <source>;
Content-Security-Policy: script-src-elem <source>;
```

### Sources

`<source>` can be any one of the values listed in CSP Source Values.

Note that this same set of values can be used in all fetch directives (and a number of other directives).

Examples
--------

### Violation case

Given this CSP header:

```http
Content-Security-Policy: script-src-elem https://example.com/
```

…the following script is blocked and won't be loaded or executed:

```html
<script src="https://not-example.com/js/library.js"></script>
```

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

| Specification |
| --- |
| Content Security Policy Level 3 # directive-script-src-elem |

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

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

See also
--------

* `Content-Security-Policy`
* `<script>`
* `script-src`
* `script-src-attr`


CSP: style-src-elem - HTTP

CSP: style-src-elem
===================

The HTTP `Content-Security-Policy` (CSP) **`style-src-elem`** directive specifies valid sources for stylesheet `<style>` elements and `<link>` elements with `rel="stylesheet"`.

The directive does not set valid sources for inline style attributes; these are set using `style-src-attr` (and valid sources for all styles may be set with `style-src`).

|  |  |
| --- | --- |
| CSP version | 3 |
| Directive type | Fetch directive |
| `default-src` fallback |
 Yes.
 If this directive is absent, the user agent will look for the `style-src` directive, and if both of them are absent, fall back to `default-src` directive.
  |

Syntax
------

One or more sources can be allowed for the `style-src-elem` policy:

```http
Content-Security-Policy: style-src-elem <source>;
Content-Security-Policy: style-src-elem <source> <source>;
```

`style-src-elem` can be used in conjunction with `style-src`:

```http
Content-Security-Policy: style-src <source>;
Content-Security-Policy: style-src-elem <source>;
```

### Sources

`<source>` can be any one of the values listed in CSP Source Values.

Note that this same set of values can be used in all fetch directives (and a number of other directives).

Examples
--------

### Violation cases

Given this CSP header:

```http
Content-Security-Policy: style-src-elem https://example.com/
```

…the following stylesheets are blocked and won't load:

```html
<link href="https://not-example.com/styles/main.css" rel="stylesheet" />

<style>
 #inline-style {
 background: red;
 }
</style>

<style>
 @import url("https://not-example.com/styles/print.css") print;
</style>
```

…as well as styles loaded using the `Link` header:

```http
Link: <https://not-example.com/styles/stylesheet.css>;rel=stylesheet
```

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

| Specification |
| --- |
| Content Security Policy Level 3 # directive-style-src-elem |

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

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

See also
--------

* `Content-Security-Policy`
* `style-src`
* `style-src-attr`
* `Link` header
* `<style>`, `<link>`
* `@import`
* `CSSStyleSheet.insertRule()`
* `CSSGroupingRule.insertRule()`
* `CSSStyleDeclaration.cssText`


CSP: worker-src - HTTP

CSP: worker-src
===============

 The HTTP `Content-Security-Policy` (CSP)
 **`worker-src`** directive specifies valid sources for
 `Worker`, `SharedWorker`, or `ServiceWorker`
 scripts.

|  |  |
| --- | --- |
| CSP version | 3 |
| Directive type | Fetch directive |
| Fallback |
 If this directive is absent, the user agent will first look for the
 `child-src` directive, then the
 `script-src` directive, then finally for the
 `default-src` directive, when governing worker
 execution.
  |

Syntax
------

One or more sources can be allowed for the `worker-src` policy:

```http
Content-Security-Policy: worker-src <source>;
Content-Security-Policy: worker-src <source> <source>;
```

### Sources

`<source>` can be any one of the values listed in CSP Source Values.

Note that this same set of values can be used in all fetch directives (and a number of other directives).

Examples
--------

### Violation cases

Given this CSP header:

```http
Content-Security-Policy: worker-src https://example.com/
```

`Worker`, `SharedWorker`, `ServiceWorker` are
 blocked and won't load:

```html
<script>
 let blockedWorker = new Worker("data:application/javascript,…");
 blockedWorker = new SharedWorker("https://not-example.com/");
 navigator.serviceWorker.register("https://not-example.com/sw.js");
</script>
```

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

| Specification |
| --- |
| Content Security Policy Level 3 # directive-worker-src |

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

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

See also
--------

* `Content-Security-Policy`
* CSP for Web Workers
* `Worker`, `SharedWorker`, `ServiceWorker`


CSP: connect-src - HTTP

CSP: connect-src
================

 The HTTP `Content-Security-Policy` (CSP)
 **`connect-src`** directive restricts the URLs which can be
 loaded using script interfaces. The APIs that are restricted are:

* `<a>` `ping`,
* `fetch()`,
* `XMLHttpRequest`,
* `WebSocket`,
* `EventSource`, and
* `Navigator.sendBeacon()`.

**Note:** `connect-src 'self'` does not resolve to websocket
 schemes in all browsers, more info in this issue.

|  |  |
| --- | --- |
| CSP version | 1 |
| Directive type | Fetch directive |
| `default-src` fallback |
 Yes. If this directive is absent, the user agent will look for the
 `default-src` directive.
  |

Syntax
------

One or more sources can be allowed for the connect-src policy:

```http
Content-Security-Policy: connect-src <source>;
Content-Security-Policy: connect-src <source> <source>;
```

### Sources

`<source>` can be any one of the values listed in CSP Source Values.

Note that this same set of values can be used in all fetch directives (and a number of other directives).

Examples
--------

### Violation cases

Given this CSP header:

```http
Content-Security-Policy: connect-src https://example.com/
```

The following connections are blocked and won't load:

```html
<a ping="https://not-example.com">
  <script>
 const response = fetch("https://not-example.com/");

 const xhr = new XMLHttpRequest();
 xhr.open("GET", "https://not-example.com/");
 xhr.send();

 const ws = new WebSocket("wss://not-example.com/");

 const es = new EventSource("https://not-example.com/");

 navigator.sendBeacon("https://not-example.com/", {
 /\* … \*/
 });
 </script></a
>
```

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

| Specification |
| --- |
| Content Security Policy Level 3 # directive-connect-src |

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

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

See also
--------

* `Content-Security-Policy`
* `<a>` `ping`
* `fetch()`
* `XMLHttpRequest`
* `WebSocket`
* `EventSource`


CSP: style-src - HTTP

CSP: style-src
==============

The HTTP `Content-Security-Policy` (CSP) **`style-src`** directive specifies valid sources for stylesheets.

|  |  |
| --- | --- |
| CSP version | 1 |
| Directive type | Fetch directive |
| `default-src` fallback |
 Yes. If this directive is absent, the user agent will look for the
 `default-src` directive.
  |

Syntax
------

One or more sources can be allowed for the `style-src` policy:

```http
Content-Security-Policy: style-src <source>;
Content-Security-Policy: style-src <source> <source>;
```

### Sources

`<source>` can be any one of the values listed in CSP Source Values.

Note that this same set of values can be used in all fetch directives (and a number of other directives).

Examples
--------

### Violation cases

Given this CSP header:

```http
Content-Security-Policy: style-src https://example.com/
```

the following stylesheets are blocked and won't load:

```html
<link href="https://not-example.com/styles/main.css" rel="stylesheet" />

<style>
 #inline-style {
 background: red;
 }
</style>

<style>
 @import url("https://not-example.com/styles/print.css") print;
</style>
```

as well as styles loaded using the `Link` header:

```http
Link: <https://not-example.com/styles/stylesheet.css>;rel=stylesheet
```

Inline style attributes are also blocked:

```html
<div style="display:none">Foo</div>
```

As well as styles that are applied in JavaScript by setting the `style` attribute directly, or by setting `cssText`:

```js
document.querySelector("div").setAttribute("style", "display:none;");
document.querySelector("div").style.cssText = "display:none;";
```

However, styles properties that are set directly on the element's `style` property will not be blocked, allowing users to safely manipulate styles via JavaScript:

```js
document.querySelector("div").style.display = "none";
```

These types of manipulations can be prevented by disallowing JavaScript via the `script-src` CSP directive.

### Unsafe inline styles

**Note:** Disallowing inline styles and inline scripts is one of the biggest security wins CSP provides. However, if you absolutely have to use it, there are a few mechanisms that will allow them.

 To allow inline styles, `'unsafe-inline'`, a nonce-source or a hash-source that matches the inline block can be specified.
 The following Content Security Policy will allow inline styles like the `<style>` element, and the `style` attribute on any element:

```http
Content-Security-Policy: style-src 'unsafe-inline';
```

The following `<style>` element and `style` attribute will be allowed by the policy:

```html
<style>
 #inline-style {
 background: red;
 }
</style>

<div style="display:none">Foo</div>
```

 You can use a nonce-source to only allow specific inline style blocks.
 You need to generate a random nonce value (using a cryptographically secure random token generator) and include it in the policy.
 It is important to note, this nonce value needs to be dynamically generated as it has to be unique for each HTTP request:

```http
Content-Security-Policy: style-src 'nonce-2726c7f26c'
```

You will have to set the same nonce on the `<style>` element:

```html
<style nonce="2726c7f26c">
 #inline-style {
 background: red;
 }
</style>
```

Alternatively, you can create hashes from your inline styles. CSP supports sha256, sha384 and sha512. The **binary** form of the hash has to be encoded with base64. You can obtain the hash of a string on the command line via the `openssl` program:

```bash
echo -n "#inline-style { background: red; }" | openssl dgst -sha256 -binary | openssl enc -base64
```

You can use a hash-source to only allow specific inline style blocks:

```http
Content-Security-Policy: style-src 'sha256-ozBpjL6dxO8fsS4u6fwG1dFDACYvpNxYeBA6tzR+FY8='
```

When generating the hash, don't include the `<style>` tags and note that capitalization and whitespace matter, including leading or trailing whitespace.

```html
<style>
 #inline-style {
 background: red;
 }
</style>
```

### Unsafe style expressions

The `'unsafe-eval'` source expression controls several style methods that create style declarations from strings. If `'unsafe-eval'` isn't specified with the `style-src` directive, the following methods are blocked and won't have any effect:

* `CSSStyleSheet.insertRule()`
* `CSSGroupingRule.insertRule()`
* `CSSStyleDeclaration.cssText`
Specifications
--------------

| Specification |
| --- |
| Content Security Policy Level 3 # directive-style-src |

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

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

See also
--------

* `Content-Security-Policy`
* `style-src-elem`
* `style-src-attr`
* `Link` header
* `<style>`, `<link>`
* `@import`
* `CSSStyleSheet.insertRule()`
* `CSSGroupingRule.insertRule()`
* `CSSStyleDeclaration.cssText`


CSP: font-src - HTTP

CSP: font-src
=============

 The HTTP `Content-Security-Policy` (CSP)
 **`font-src`** directive specifies
 valid sources for fonts loaded using `@font-face`.

|  |  |
| --- | --- |
| CSP version | 1 |
| Directive type | Fetch directive |
| `default-src` fallback |
 Yes. If this directive is absent, the user agent will look for the
 `default-src` directive.
  |

Syntax
------

One or more sources can be allowed for the `font-src` policy:

```http
Content-Security-Policy: font-src <source>;
Content-Security-Policy: font-src <source> <source>;
```

### Sources

`<source>` can be any one of the values listed in CSP Source Values.

Note that this same set of values can be used in all fetch directives (and a number of other directives).

Examples
--------

### Violation cases

Given this CSP header:

```http
Content-Security-Policy: font-src https://example.com/
```

The following font resource loading is blocked and won't load:

```html
<style>
 @font-face {
 font-family: "MyFont";
 src: url("https://not-example.com/font");
 }
 body {
 font-family: "MyFont";
 }
</style>
```

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

| Specification |
| --- |
| Content Security Policy Level 3 # directive-font-src |

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

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

See also
--------

* `Content-Security-Policy`
* `@font-face`


CSP: referrer - HTTP

CSP: referrer
=============

**Deprecated:** This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.

**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.

 The HTTP `Content-Security-Policy` (CSP)
 **`referrer`** directive used to specify information in the
 `Referer` header (with a single `r` as this was a typo in the
 original spec) for links away from a page. This API is deprecated and removed from
 browsers.

**Note:** Use the `Referrer-Policy` header instead.

Syntax
------

```http
Content-Security-Policy: referrer <referrer-policy>;
```

where `<referrer-policy>` can be one of the following values:

"no-referrer"

 The `Referer` header will be omitted entirely. No referrer
 information is sent along with requests.

"none-when-downgrade"

 This is the user agent's default behavior if no policy is specified. The origin is
 sent as referrer to a-priori as-much-secure destination (HTTPS->HTTPS), but isn't
 sent to a less secure destination (HTTPS->HTTP).

"origin"

 Only send the origin of the document as the referrer in all cases.
 The document `https://example.com/page.html` will send the referrer
 `https://example.com/`.

"origin-when-cross-origin" / "origin-when-crossorigin"

 Send a full URL when performing a same-origin request, but only send the origin of
 the document for other cases.

"unsafe-url"

 Send a full URL (stripped from parameters) when performing a same-origin or
 cross-origin request. This policy will leak origins and paths from TLS-protected
 resources to insecure origins. Carefully consider the impact of this setting.

Examples
--------

```http
Content-Security-Policy: referrer "none";
```

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

Not part of any specification.

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

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

See also
--------

* `Content-Security-Policy`
* `Referrer-Policy` header
* `Referer` header


CSP: script-src-attr - HTTP

CSP: script-src-attr
====================

The HTTP `Content-Security-Policy` (CSP) **`script-src-attr`** directive specifies valid sources for JavaScript inline event handlers.

 This directive only specifies valid sources for inline script event handlers like `onclick`.
 It does not apply to other JavaScript sources that can trigger script execution, such as URLs loaded directly into `<script>` elements and XSLT stylesheets.
 (Valid sources can be specified for all JavaScript script sources using `script-src`, or just for `<script>` elements using `script-src-elem`.)

|  |  |
| --- | --- |
| CSP version | 3 |
| Directive type | Fetch directive |
| `default-src` fallback |
 Yes.
 If this directive is absent, the user agent will look for the `script-src` directive, and if both of them are absent, fallback to `default-src` directive.
  |

Syntax
------

One or more sources can be allowed for the `script-src-attr` policy:

```http
Content-Security-Policy: script-src-attr <source>;
Content-Security-Policy: script-src-attr <source> <source>;
```

`script-src-attr` can be used in conjunction with `script-src`, and will override that directive for checks on inline handlers:

```http
Content-Security-Policy: script-src <source>;
Content-Security-Policy: script-src-attr <source>;
```

### Sources

`<source>` can be any one of the values listed in CSP Source Values.

Note that this same set of values can be used in all fetch directives (and a number of other directives).

Examples
--------

### Violation case

Given this CSP header:

```http
Content-Security-Policy: script-src-attr 'none'
```

…the following inline event handler is blocked and won't be loaded or executed:

```html
<button id="btn" onclick="doSomething()"></button>
```

Note that generally you should replace inline event handlers with `addEventListener` calls:

```js
document.getElementById("btn").addEventListener("click", doSomething);
```

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

| Specification |
| --- |
| Content Security Policy Level 3 # directive-script-src-attr |

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

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

See also
--------

* `Content-Security-Policy`
* `<script>`
* `script-src`
* `script-src-elem`


CSP: upgrade-insecure-requests - HTTP

CSP: upgrade-insecure-requests
==============================

 The HTTP `Content-Security-Policy` (CSP)
 **`upgrade-insecure-requests`** directive instructs user
 agents to treat all of a site's insecure URLs (those served over HTTP) as though they
 have been replaced with secure URLs (those served over HTTPS). This directive is
 intended for websites with large numbers of insecure legacy URLs that need to be
 rewritten.

**Note:** The `upgrade-insecure-requests` directive is evaluated before
 `block-all-mixed-content` and if it is set, the latter is effectively a
 no-op. It is recommended to set either directive, but not both, unless you want to
 force HTTPS on older browsers that do not force it after a redirect to HTTP.

 The `upgrade-insecure-requests` directive will not ensure that users
 visiting your site via links on third-party sites will be upgraded to HTTPS for the
 top-level navigation and thus does not replace the
 `Strict-Transport-Security` (HSTS) header, which
 should still be set with an appropriate `max-age` to ensure that users are
 not subject to SSL stripping attacks.

Syntax
------

```http
Content-Security-Policy: upgrade-insecure-requests;
```

Examples
--------

### Using the HTTP header

```http
Content-Security-Policy: upgrade-insecure-requests;
```

### Using the HTML meta element

```html
<meta
 http-equiv="Content-Security-Policy"
 content="upgrade-insecure-requests" />
```

 With the above header set on a domain example.com that wants to migrate from HTTP to
 HTTPS, non-navigational insecure resource requests are automatically upgraded
 (first-party as well as third-party requests).

```html
<img src="http://example.com/image.png" />
<img src="http://not-example.com/image.png" />
```

 These URLs will be rewritten before the request is made, meaning that no insecure
 requests will hit the network. Note that, if the requested resource is not actually
 available via HTTPS, the request will fail without any fallback to HTTP.

```html
<img src="https://example.com/image.png" />
<img src="https://not-example.com/image.png" />
```

 Navigational upgrades to third-party resources brings a significantly higher potential
 for breakage, these are not upgraded:

```html
<a href="https://example.com/">Home</a>
<a href="http://not-example.com/">Home</a>
```

### Finding insecure requests

 With the help of the `Content-Security-Policy-Report-Only` header and
 the `report-uri` directive, you can set-up an enforced policy and a reported
 policy like this:

```http
Content-Security-Policy: upgrade-insecure-requests; default-src https:
Content-Security-Policy-Report-Only: default-src https:; report-uri /endpoint
```

 That way, you still upgrade insecure requests on your secure site, but the only
 monitoring policy is violated and reports insecure resources to your endpoint.

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

| Specification |
| --- |
| Upgrade Insecure Requests # delivery |

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

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

See also
--------

* `Content-Security-Policy`
* `Upgrade-Insecure-Requests` header
* `Strict-Transport-Security` (HSTS) header
* `block-all-mixed-content`
* Mixed content


CSP: img-src - HTTP

CSP: img-src
============

The HTTP `Content-Security-Policy` **`img-src`** directive specifies valid sources of images and favicons.

|  |  |
| --- | --- |
| CSP version | 1 |
| Directive type | Fetch directive |
| `default-src` fallback |
 Yes. If this directive is absent, the user agent will look for the
 `default-src` directive.
  |

Syntax
------

One or more sources can be allowed for the `img-src` policy:

```http
Content-Security-Policy: img-src <source>;
Content-Security-Policy: img-src <source> <source>;
```

### Sources

`<source>` can be any one of the values listed in CSP Source Values.

Note that this same set of values can be used in all fetch directives (and a number of other directives).

Examples
--------

### Violation cases

Given this CSP header:

```http
Content-Security-Policy: img-src https://example.com/
```

The following `<img>` is blocked and won't load:

```html
<img src="https://not-example.com/foo.jpg" alt="example picture" />
```

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

| Specification |
| --- |
| Content Security Policy Level 3 # directive-img-src |

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

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

See also
--------

* `Content-Security-Policy`
* `<img>`


CSP: style-src-attr - HTTP

CSP: style-src-attr
===================

The HTTP `Content-Security-Policy` (CSP) **`style-src-attr`** directive specifies valid sources for inline styles applied to individual DOM elements.

 The directive does not set valid sources for `<style>` elements and `<link>` elements with `rel="stylesheet"`.
 These are set using `style-src-elem` (and valid sources for all styles may be set with `style-src`).

|  |  |
| --- | --- |
| CSP version | 3 |
| Directive type | Fetch directive |
| `default-src` fallback |
 Yes.
 If this directive is absent, the user agent will look for the `style-src` directive, and if both of them are absent, fallback to `default-src` directive.
  |

Syntax
------

One or more sources can be allowed for the `style-src-attr` policy:

```http
Content-Security-Policy: style-src-attr <source>;
Content-Security-Policy: style-src-attr <source> <source>;
```

`style-src-attr` can be used in conjunction with `style-src`:

```http
Content-Security-Policy: style-src <source>;
Content-Security-Policy: style-src-attr <source>;
```

### Sources

`<source>` can be any one of the values listed in CSP Source Values.

Note that this same set of values can be used in all fetch directives (and a number of other directives).

Examples
--------

### Violation cases

Given this CSP header:

```http
Content-Security-Policy: style-src-attr 'none'
```

…the inline style applied to the element below will not be applied:

```html
<div style="display:none">Foo</div>
```

The policy would also block any styles applied in JavaScript by setting the `style` attribute directly, or by setting `cssText`:

```js
document.querySelector("div").setAttribute("style", "display:none;");
document.querySelector("div").style.cssText = "display:none;";
```

Style properties that are set directly on the element's `style` property will not be blocked, allowing users to safely manipulate styles via JavaScript:

```js
document.querySelector("div").style.display = "none";
```

Note that using JavaScript might independently be blocked using the `script-src` CSP directive.

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

| Specification |
| --- |
| Content Security Policy Level 3 # directive-style-src-attr |

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

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

See also
--------

* `Content-Security-Policy`
* `style-src`
* `style-src-elem`
* `Link` header
* `<style>`, `<link>`
* `@import`
* `CSSStyleSheet.insertRule()`
* `CSSGroupingRule.insertRule()`
* `CSSStyleDeclaration.cssText`


CSP: manifest-src - HTTP

CSP: manifest-src
=================

 The HTTP
 `Content-Security-Policy``: manifest-src`
 directive specifies which manifest can be applied
 to the resource.

|  |  |
| --- | --- |
| CSP version | 3 |
| Directive type | Fetch directive |
| `default-src` fallback |
 Yes. If this directive is absent, the user agent will look for the
 `default-src` directive.
  |

Syntax
------

One or more sources can be allowed for the `manifest-src` policy:

```http
Content-Security-Policy: manifest-src <source>;
Content-Security-Policy: manifest-src <source> <source>;
```

### Sources

`<source>` can be any one of the values listed in CSP Source Values.

Note that this same set of values can be used in all fetch directives (and a number of other directives).

Examples
--------

### Violation cases

Given this CSP header:

```http
Content-Security-Policy: manifest-src https://example.com/
```

The following `<link>` is blocked and won't load:

```html
<link rel="manifest" href="https://not-example.com/manifest" />
```

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

| Specification |
| --- |
| Content Security Policy Level 3 # directive-manifest-src |

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

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

See also
--------

* `Content-Security-Policy`
* Web app manifest
* `<link>`


Permissions-Policy: microphone - HTTP

Permissions-Policy: microphone
==============================

The HTTP `Permissions-Policy` header `microphone` directive controls whether the current document is allowed to use audio input devices.

 Specifically, where a defined policy blocks use of this feature, `MediaDevices.getUserMedia()` calls will return a `Promise`
 that rejects with a `NotAllowedError` `DOMException`.

Syntax
------

```http
Permissions-Policy: microphone=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `microphone` is `self`.

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

| Specification |
| --- |
| Media Capture and Streams # permissions-policy-integration |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: display-capture - HTTP

Permissions-Policy: display-capture
===================================

The HTTP `Permissions-Policy` header `display-capture` directive controls whether or not the document is permitted to use Screen Capture API, that is, `getDisplayMedia()` to capture the screen's contents.

If `display-capture` is disabled in a document, the document will not be able to initiate screen capture via `getDisplayMedia()` and will throw a `NotAllowedError` exception.

Syntax
------

```http
Permissions-Policy: display-capture=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `display-capture` is `self`.

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

| Specification |
| --- |
| Screen Capture # permissions-policy-integration |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy
* Screen Capture API
* Using the Screen Capture API


Permissions-Policy: autoplay - HTTP

Permissions-Policy: autoplay
============================

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

 The HTTP `Permissions-Policy` header
 `autoplay` directive controls whether the current document is allowed to
 autoplay media requested through the `HTMLMediaElement` interface.

 Specifically, where a defined policy blocks use of this feature and there were no user gestures, the `Promise`
 returned by `HTMLMediaElement.play()` will reject with
 a `DOMException`. The `autoplay` attribute on
 `<audio>` and `<video>` elements will be ignored.

**Note:** For more details on autoplay and autoplay blocking, see the article Autoplay guide for media and Web Audio APIs.

Syntax
------

```http
Permissions-Policy: autoplay=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `autoplay` is `self`.

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

| Specification |
| --- |
| HTML Standard # autoplay-feature |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: ambient-light-sensor - HTTP

Permissions-Policy: ambient-light-sensor
========================================

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

The HTTP `Permissions-Policy` header `ambient-light-sensor` directive controls whether the current document is allowed to gather information about the amount of light in the environment around the device through the `AmbientLightSensor` interface.

Specifically, where a defined policy blocks use of this feature, `AmbientLightSensor()` constructor calls will throw a `DOMException` of type `SecurityError`.

Syntax
------

```http
Permissions-Policy: ambient-light-sensor=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `ambient-light-sensor` is `self`.

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

| Specification |
| --- |
| Generic Sensor API # permissions-policy |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: publickey-credentials-get - HTTP

Permissions-Policy: publickey-credentials-get
=============================================

The HTTP `Permissions-Policy` header `publickey-credentials-get` directive controls whether the current document is allowed to access the Web Authentication API to retrieve public-key credentials, i.e., via `navigator.credentials.get({publicKey})`.

Specifically, where a defined policy blocks the use of this feature, the `Promise` returned by `navigator.credentials.get({publicKey})` will reject with a `SecurityError` `DOMException`.

Syntax
------

```http
Permissions-Policy: publickey-credentials-get=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `publickey-credentials-get` is `self`.

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

| Specification |
| --- |
| Web Authentication: An API for accessing Public Key Credentials - Level 3 # sctn-permissions-policy |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy
* Web Authentication API
* `PublicKeyCredential` interface


Permissions-Policy: window-management - HTTP

Permissions-Policy: window-management
=====================================

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

The HTTP `Permissions-Policy` header `window-management` directive controls whether or not the current document is allowed to use the Window Management API to manage windows on multiple displays.

Where this policy forbids use of the API:

* The `Promise` returned by the `Window.getScreenDetails()` method will reject with a `NotAllowedError` exception.
* The `Window.screen.isExtended` property will always return `false`.
Syntax
------

```http
Permissions-Policy: window-management=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `window-management` is `self`.

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

| Specification |
| --- |
| Window Management # api-permission-policy-integration |

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

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

See also
--------

* Window Management API
* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: local-fonts - HTTP

Permissions-Policy: local-fonts
===============================

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

The HTTP `Permissions-Policy` header `local-fonts` directive controls whether the current document is allowed to gather data on the user's locally-installed fonts via the `Window.queryLocalFonts()` method.

Specifically, where a defined policy blocks use of this feature, `Promise`s returned by `Window.queryLocalFonts()` will reject with a `DOMException` of type `SecurityError`.

Syntax
------

```http
Permissions-Policy: local-fonts=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `local-fonts` is `self`.

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

| Specification |
| --- |
| Local Font Access # permissions-policy |

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

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

See also
--------

* Local Font Access API
* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: execution-while-out-of-viewport - HTTP

Permissions-Policy: execution-while-out-of-viewport
===================================================

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

The HTTP `Permissions-Policy` header `execution-while-out-of-viewport` directive controls whether tasks should execute in frames while they're outside of the visible viewport.

Specifically, where a defined policy blocks execution of task rendering while content is not in the visible viewport, while that condition is true, the content will be put in the frozen state as defined in the Page Lifecycle API. This stops execution of freezable tasks such as JavaScript timers (e.g. `setTimeout()`) and `fetch()` callbacks.

Syntax
------

```http
Permissions-Policy: execution-while-out-of-viewport=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `execution-while-out-of-viewport` is `*`.

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

| Specification |
| --- |
| Page Lifecycle # feature-policies |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: geolocation - HTTP

Permissions-Policy: geolocation
===============================

 The HTTP `Permissions-Policy` header
 `geolocation` directive controls whether the current document is allowed to
 use the `Geolocation` Interface.

 Specifically, where a defined policy blocks use of this feature, calls to
 `getCurrentPosition()` and
 `watchPosition()` will cause those functions'
 callbacks to be invoked with a `GeolocationPositionError` code of
 `PERMISSION_DENIED`.

 By default, the Geolocation API can be used within top-level documents and their
 same-origin child frames. This directive allows or prevents cross-origin frames from
 accessing geolocation. This includes same-origin frames.

Syntax
------

```http
Permissions-Policy: geolocation=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `geolocation` is `self`.

Examples
--------

### General example

 SecureCorp Inc. wants to disable the Geolocation API within all browsing contexts
 except for its own origin and those whose origin is `https://example.com`. It
 can do so by delivering the following HTTP response header to define a Permissions Policy:

```http
Permissions-Policy: geolocation=(self "https://example.com")
```

### With an <iframe> element

 FastCorp Inc. wants to disable `geolocation` for all cross-origin child
 frames, except for a specific `<iframe>`. It can do so by delivering the following
 HTTP response header to define a Permissions Policy:

```http
Permissions-Policy: geolocation=(self)
```

 Then include an allow attribute on the
 `<iframe>` element:

```html
<iframe src="https://other.com/map" allow="geolocation"></iframe>
```

 Interestingly, `allow` attributes can selectively enable features in certain frames, and not in others,
 even if those frames contain documents from the same origin.

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

| Specification |
| --- |
| Geolocation API # permissions-policy |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: battery - HTTP

Permissions-Policy: battery
===========================

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

The HTTP `Permissions-Policy` header `battery` directive controls whether the current document is allowed to gather information about the battery of the device through the `BatteryManager` interface obtained via `Navigator.getBattery()`.

Specifically, where a defined policy blocks use of this feature, `getBattery()` calls will return a `Promise` that rejects with a `DOMException` of type `NotAllowedError`.

Syntax
------

```http
Permissions-Policy: battery=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `battery` is `self`.

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

| Specification |
| --- |
| Battery Status API # permissions-policy-integration |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy
* Battery Status API
* `Navigator.getBattery()`
* `BatteryManager`


Permissions-Policy: idle-detection - HTTP

Permissions-Policy: idle-detection
==================================

Limited availability
--------------------

This feature is not Baseline because it does not work in some of the most widely-used browsers.

* Learn more
* See full compatibility
* Report feedback
**Experimental:** **This is an experimental technology**
Check the Browser compatibility table carefully before using this in production.

The HTTP `Permissions-Policy` header `idle-detection` directive controls whether the current document is allowed to use the Idle Detection API to detect when users are interacting with their devices, for example to report "available"/"away" status in chat applications.

Specifically, where a defined policy blocks use of this feature, `IdleDetector.start()` calls will return a `Promise` that rejects with a `DOMException` of type `NotAllowedError`.

Syntax
------

```http
Permissions-Policy: idle-detection=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `idle-detection` is `self`.

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

| Specification |
| --- |
| Idle Detection API # api-permissions-policy |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: magnetometer - HTTP

Permissions-Policy: magnetometer
================================

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

The HTTP `Permissions-Policy` header `magnetometer` directive controls whether the current document is allowed to gather information about the orientation of the device through the `Magnetometer` interface.

Specifically, where a defined policy blocks use of this feature, `Magnetometer()` constructor calls will throw a `DOMException` of type `SecurityError`.

Syntax
------

```http
Permissions-Policy: magnetometer=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `magnetometer` is `self`.

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

| Specification |
| --- |
| Generic Sensor API # permissions-policy |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: camera - HTTP

Permissions-Policy: camera
==========================

 The HTTP `Permissions-Policy` header
 `camera` directive controls whether the current document is allowed to use
 video input devices.

Specifically, where a defined policy blocks use of this feature, `MediaDevices.getUserMedia()` calls will return a `Promise` that rejects with a `NotAllowedError` `DOMException`.

Syntax
------

```http
Permissions-Policy: camera=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `camera` is `self`.

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

| Specification |
| --- |
| Media Capture and Streams # permissions-policy-integration |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: web-share - HTTP

Permissions-Policy: web-share
=============================

The HTTP `Permissions-Policy` header `web-share` directive controls whether the current document is allowed to use the `Navigator.share()` method of the Web Share API to share text, links, images, and other content to arbitrary destinations of the user's choice.

Specifically, where a defined policy blocks usage of this feature, `Navigator.share()` calls will return a `Promise` that rejects with a `DOMException` of type `NotAllowedError`.

Syntax
------

```http
Permissions-Policy: web-share=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `web-share` is `self`.

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

| Specification |
| --- |
| Web Share API # permissions-policy |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: identity-credentials-get - HTTP

Permissions-Policy: identity-credentials-get
============================================

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

The HTTP `Permissions-Policy` header `identity-credentials-get` directive controls whether the current document is allowed to use the Federated Credential Management API (FedCM), and more specifically the `navigator.credentials.get()` method with an `identity` option.

Where this policy forbids use of the API, the `Promise` returned by the `get()` call will reject with a `NotAllowedError` `DOMException`.

Syntax
------

```http
Permissions-Policy: identity-credentials-get=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `identity-credentials-get` is `self`.

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

| Specification |
| --- |
| Federated Credential Management API # permissions-policy-integration |

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

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

See also
--------

* Federated Credential Management API (FedCM)
* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: publickey-credentials-create - HTTP

Permissions-Policy: publickey-credentials-create
================================================

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

The HTTP `Permissions-Policy` header `publickey-credentials-create` directive controls whether the current document is allowed to use the Web Authentication API to create new WebAuthn credentials, i.e., via `navigator.credentials.create({publicKey})`.

Specifically, where a defined policy blocks use of this feature, the `Promise` returned by `navigator.credentials.create({publicKey})` will reject with a `SecurityError` `DOMException`.

Syntax
------

```http
Permissions-Policy: publickey-credentials-create=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `publickey-credentials-create` is `self`.

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

| Specification |
| --- |
| Web Authentication: An API for accessing Public Key Credentials - Level 3 # sctn-permissions-policy |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy
* Web Authentication API
* `PublicKeyCredential` interface


Permissions-Policy: screen-wake-lock - HTTP

Permissions-Policy: screen-wake-lock
====================================

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

The HTTP `Permissions-Policy` header **`screen-wake-lock`** directive controls whether the current document is allowed to use Screen Wake Lock API to indicate that the device should not dim or turn off the screen.

Specifically, where a defined policy blocks use of this feature, `WakeLock.request()` calls will return a `Promise` that rejects with a `DOMException` of type `NotAllowedError`.

Syntax
------

```http
Permissions-Policy: screen-wake-lock=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `screen-wake-lock` is `self`.

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

| Specification |
| --- |
| Screen Wake Lock API # policy-control |

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

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

See also
--------

* Screen Wake Lock API
* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: document-domain - HTTP

Permissions-Policy: document-domain
===================================

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

 The HTTP `Permissions-Policy` header
 `document-domain` directive controls whether the current document is
 allowed to set `document.domain`.

 Specifically, where a defined policy blocks use of this feature, attempting
 to set `document.domain` will fail and cause a `SecurityError`
`DOMException` to be thrown.

Syntax
------

```http
Permissions-Policy: document-domain=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `document-domain` is `*`.

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

| Specification |
| --- |
| HTML Standard # policy-controlled-features |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: fullscreen - HTTP

Permissions-Policy: fullscreen
==============================

The HTTP `Permissions-Policy` header `fullscreen` directive controls whether the current document is allowed to use `Element.requestFullscreen()`.

By default, top-level documents and their same-origin child frames can request and enter fullscreen mode. This directive allows or prevents cross-origin frames from using fullscreen mode. This includes same-origin frames.

Specifically, where a defined policy blocks use of this feature, `requestFullscreen()` calls will return a `Promise` that rejects with a `TypeError`.

**Note:** If both this directive (i.e. via the `allow` attribute) and the `allowfullscreen` attribute are present on an `<iframe>` element, this directive takes precedence.

Syntax
------

```http
Permissions-Policy: fullscreen=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `fullscreen` is `self`.

Examples
--------

### General example

SecureCorp Inc. wants to disable the Fullscreen API within all browsing contexts except for its own origin and those whose origin is `https://example.com`. It can do so by delivering the following HTTP response header to define a Permissions Policy:

```http
Permissions-Policy: fullscreen=(self "https://example.com")
```

### With an <iframe> element

FastCorp Inc. wants to disable `fullscreen` for all cross-origin child frames, except for a specific `<iframe>`. It can do so by delivering the following HTTP response header to define a Permissions Policy:

```http
Permissions-Policy: fullscreen=(self)
```

Then include an allow attribute on the `<iframe>` element:

```html
<iframe src="https://other.com/videoplayer" allow="fullscreen"></iframe>
```

iframe attributes can selectively enable features in certain frames, and not in others, even if those frames contain documents from the same origin.

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

| Specification |
| --- |
| Fullscreen API Standard # permissions-policy-integration |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: storage-access - HTTP

Permissions-Policy: storage-access
==================================

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

The HTTP `Permissions-Policy` header `storage-access` directive controls whether a document loaded in a third-party context (i.e. embedded in an `<iframe>`) is allowed to use the Storage Access API to request access to unpartitioned cookies.

This is relevant to user agents that by default block access to unpartitioned cookies by sites loaded in a third-party context to improve privacy (for example, to prevent tracking).

Specifically, where a defined policy blocks use of this feature, `Document.requestStorageAccess()` calls will return a `Promise` that rejects with a `DOMException` of type `NotAllowedError`.

Syntax
------

```http
Permissions-Policy: storage-access=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `storage-access` is `*`.

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

| Specification |
| --- |
| The Storage Access API # permissions-policy-integration |

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

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

See also
--------

* Storage Access API
* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: encrypted-media - HTTP

Permissions-Policy: encrypted-media
===================================

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

The HTTP `Permissions-Policy` header `encrypted-media` directive controls whether the current document is allowed to use the Encrypted Media Extensions API (EME).

Specifically, where a defined policy blocks use of this feature, the `Promise` returned by `Navigator.requestMediaKeySystemAccess()` will reject with a `DOMException` of type `SecurityError`.

Syntax
------

```http
Permissions-Policy: encrypted-media=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `encrypted-media` is `self`.

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

| Specification |
| --- |
| Encrypted Media Extensions # permissions-policy-integration |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: gyroscope - HTTP

Permissions-Policy: gyroscope
=============================

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

The HTTP `Permissions-Policy` header `gyroscope` directive controls whether the current document is allowed to gather information about the orientation of the device through the `Gyroscope` interface.

Specifically, where a defined policy blocks use of this feature, `Gyroscope()` constructor calls will throw a `DOMException` of type `SecurityError`.

Syntax
------

```http
Permissions-Policy: gyroscope=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `gyroscope` is `self`.

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

| Specification |
| --- |
| Generic Sensor API # permissions-policy |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: gamepad - HTTP

Permissions-Policy: gamepad
===========================

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

The HTTP `Permissions-Policy` header `gamepad` directive controls whether the current document is allowed to use the Gamepad API.

Specifically, where a defined policy blocks use of this feature, calls to `Navigator.getGamepads()` will throw a `SecurityError` `DOMException`. In addition, the `gamepadconnected` and `gamepaddisconnected` events will not fire.

Syntax
------

```http
Permissions-Policy: gamepad=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `gamepad` is `self`.

Examples
--------

### General example

 SecureCorp Inc. wants to disable the Gamepad API within all browsing contexts except for its own origin and those whose origin is `https://example.com`.
 It can do so by delivering the following HTTP response header to define a Permissions Policy:

```http
Permissions-Policy: gamepad=(self "https://example.com")
```

### With an <iframe> element

 FastCorp Inc. wants to disable `gamepad` for all cross-origin child frames, except for a specific `<iframe>`.
 It can do so by delivering the following HTTP response header to define a Permissions Policy:

```http
Permissions-Policy: gamepad=(self)
```

Then include an allow attribute on the `<iframe>` element:

```html
<iframe src="https://other.com/game" allow="gamepad"></iframe>
```

iframe attributes can selectively enable features in certain frames, and not in others, even if those frames contain documents from the same origin.

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

| Specification |
| --- |
| Gamepad # permission-policy |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: hid - HTTP

Permissions-Policy: hid
=======================

Limited availability
--------------------

This feature is not Baseline because it does not work in some of the most widely-used browsers.

* Learn more
* See full compatibility
* Report feedback
**Experimental:** **This is an experimental technology**
Check the Browser compatibility table carefully before using this in production.

The HTTP `Permissions-Policy` header `hid` directive controls whether the current document is allowed to use the WebHID API to connect to uncommon or exotic human interface devices such as alternative keyboards or gamepads.

Specifically, where a defined policy blocks WebHID usage, the `Navigator.hid` property will not be available.

Syntax
------

```http
Permissions-Policy: hid=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `hid` is `self`.

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

| Specification |
| --- |
| WebHID API # permissions-policy |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: xr-spatial-tracking - HTTP

Permissions-Policy: xr-spatial-tracking
=======================================

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

The HTTP `Permissions-Policy` header `xr-spatial-tracking` directive controls whether the current document is allowed to use the WebXR Device API.

Specifically, where a defined policy blocks usage of this feature:

* `navigator.xr.isSessionSupported()` and `navigator.xr.requestSession()` calls will return a `Promise` that rejects with a `DOMException` of type `SecurityError`.
* `devicechange` events are not fired on the `navigator.xr` object.
Syntax
------

```http
Permissions-Policy: xr-spatial-tracking=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `xr-spatial-tracking` is `self`.

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

| Specification |
| --- |
| WebXR Device API # permissions-policy |

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

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

See also
--------

* WebXR Device API
* `navigator.xr.requestSession()`, and `navigator.xr.isSessionSupported()` and `devicechange` event on `navigator.xr`
* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: picture-in-picture - HTTP

Permissions-Policy: picture-in-picture
======================================

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

The HTTP `Permissions-Policy` header `picture-in-picture` directive controls whether the current document is allowed to play a video in a Picture-in-Picture mode.

Specifically, where a defined policy blocks use of this feature, `HTMLVideoElement.requestPictureInPicture()` calls will throw a `DOMException` of type `SecurityError`.

Syntax
------

```http
Permissions-Policy: picture-in-picture=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `picture-in-picture` is `*`.

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

| Specification |
| --- |
| Picture-in-Picture # permissions-policy |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: payment - HTTP

Permissions-Policy: payment
===========================

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

The HTTP `Permissions-Policy` header field's `payment` directive controls whether the current document is allowed to use the Payment Request API.

Specifically, where a defined policy blocks use of this feature, `PaymentRequest()` constructor calls will throw a `DOMException` of type `SecurityError`.

Syntax
------

```http
Permissions-Policy: payment=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `payment` is `self`.

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

| Specification |
| --- |
| Payment Request API 1.1 # permissions-policy |

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

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

See also
--------

* `Permissions-Policy` header field
* Permissions Policy


Permissions-Policy: speaker-selection - HTTP

Permissions-Policy: speaker-selection
=====================================

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

The HTTP `Permissions-Policy` header `speaker-selection` directive controls whether the current document is allowed to enumerate and select audio output devices (speakers, headphones, and so on).

Specifically, where a defined policy blocks use of this feature:

* `MediaDevices.enumerateDevices()` won't return devices of type *audio output*.
* `MediaDevices.selectAudioOutput()` won't display the popup for selecting an audio output, and the returned `Promise` will reject with a `DOMException` of type `NotAllowedError`.
* `HTMLMediaElement.setSinkId()` and `AudioContext.setSinkId()` will throw a `NotAllowedError` if called for an audio output.
Syntax
------

```http
Permissions-Policy: speaker-selection=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `speaker-selection` is `self`.

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

| Specification |
| --- |
| Audio Output Devices API # permissions-policy-integration |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: accelerometer - HTTP

Permissions-Policy: accelerometer
=================================

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

The HTTP `Permissions-Policy` header `accelerometer` directive controls whether the current document is allowed to gather information about the acceleration of the device through the `Accelerometer` interface.

Specifically, where a defined policy blocks use of this feature, `Accelerometer()` constructor calls will throw a `DOMException` of type `SecurityError`.

Syntax
------

```http
Permissions-Policy: accelerometer=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `accelerometer` is: `self`.

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

| Specification |
| --- |
| Generic Sensor API # permissions-policy |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: midi - HTTP

Permissions-Policy: midi
========================

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

The HTTP `Permissions-Policy` header `midi` directive controls whether the current document is allowed to use the Web MIDI API.

Specifically, where a defined policy blocks use of this feature, `Navigator.requestMIDIAccess()` calls will return a `Promise` that rejects with a `DOMException` of type `SecurityError`.

Syntax
------

```http
Permissions-Policy: midi=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `midi` is `self`.

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

| Specification |
| --- |
| Web MIDI API # permissions-policy-integration |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: usb - HTTP

Permissions-Policy: usb
=======================

Limited availability
--------------------

This feature is not Baseline because it does not work in some of the most widely-used browsers.

* Learn more
* See full compatibility
* Report feedback
**Experimental:** **This is an experimental technology**
Check the Browser compatibility table carefully before using this in production.

The HTTP `Permissions-Policy` header `usb` directive controls whether the current document is allowed to use the WebUSB API.

Specifically, where a defined policy blocks WebHID usage, the `Navigator.usb` property will not be available.

Syntax
------

```http
Permissions-Policy: usb=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `usb` is `self`.

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

| Specification |
| --- |
| WebUSB API # permissions-policy |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: otp-credentials - HTTP

Permissions-Policy: otp-credentials
===================================

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

The HTTP `Permissions-Policy` header `otp-credentials` directive controls whether the current document is allowed to use the WebOTP API to request a one-time password (OTP) from a specially-formatted SMS message sent by the app's server, i.e., via `navigator.credentials.get({otp: ..., ...})`.

Specifically, where a defined policy blocks the use of this feature, the `Promise` returned by `navigator.credentials.get({otp})` will reject with a `SecurityError` `DOMException`.

Syntax
------

```http
Permissions-Policy: otp-credentials=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `otp-credentials` is `self`.

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

| Specification |
| --- |
| WebOTP API # sctn-permissions-policy |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy
* WebOTP API
* `OTPCredential` interface


Permissions-Policy: execution-while-not-rendered - HTTP

Permissions-Policy: execution-while-not-rendered
================================================

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

The HTTP `Permissions-Policy` header `execution-while-not-rendered` directive controls whether tasks should execute in frames while they're not being rendered (e.g. if an iframe is `hidden` or has `display: none` set).

Specifically, where a defined policy blocks execution of task rendering while content is not being rendered, while that condition is true, that content will be put in the frozen state as defined in the Page Lifecycle API. This stops execution of freezable tasks such as JavaScript timers (e.g. `setTimeout()`) and `fetch()` callbacks.

Syntax
------

```http
Permissions-Policy: execution-while-not-rendered=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `execution-while-not-rendered` is `*`.

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

| Specification |
| --- |
| Page Lifecycle # feature-policies |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy


Permissions-Policy: serial - HTTP

Permissions-Policy: serial
==========================

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

The HTTP `Permissions-Policy` header `serial` directive controls whether the current document is allowed to use the Web Serial API to communicate with serial devices, either directly connected via a serial port, or via USB or Bluetooth devices emulating a serial port.

Specifically, where a defined policy blocks use of this feature, `Serial.requestPort()` and `Serial.getPorts()` calls will return a `Promise` that rejects with a `DOMException` of type `SecurityError`.

Syntax
------

```http
Permissions-Policy: serial=<allowlist>;
```

`<allowlist>`

A list of origins for which permission is granted to use the feature. See `Permissions-Policy` > Syntax for more details.

Default policy
--------------

The default allowlist for `serial` is `self`.

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

| Specification |
| --- |
| Web Serial API # permissions-policy |

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

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

See also
--------

* `Permissions-Policy` header
* Permissions Policy