The HTTP Permissions-Policyresponse header provides a mechanism to allow and deny the use of browser features in a document or within any elements in the document.
The feature will be allowed in this document, and in all nested browsing contexts (s) in the same origin only. The feature is not allowed in cross-origin documents in nested browsing contexts. self can be considered shorthand for https://your-site.example.com. The equivalent for allow attributes is self.
The feature will be allowed in this , as long as the document loaded into it comes from the same origin as the URL in its src attribute. This value is only used in the allow attribute, and is the defaultallowlist value in s.
The feature is allowed for specific origins (for example, "https://a.example.com"). Origins should be separated by spaces. Note that origins in allow attributes are not quoted.
The values * and () may only be used on their own, while self and src may be used in combination with one or more origins.
Note:
Directives have a default allowlist, which is always one of *, self, or none for the Permissions-Policy HTTP header, and governs the default behavior if they are not explicitly listed in a policy.
These are specified on the individual directive reference pages. For allow attributes, the default behavior is always src.
Where supported, you can include wildcards in Permissions Policy origins. This means that instead of having to explicitly specify several different subdomains in an allowlist, you can specify them all in a single origin with a wildcard.
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.
Controls whether the current document is allowed to autoplay media requested through the HTMLMediaElement interface. When this policy is disabled and there were no user gestures, the Promise returned by HTMLMediaElement.play() will reject with a NotAllowedErrorDOMException. The autoplay attribute on and elements will be ignored.
Controls whether the current document is allowed to use video input devices. When this policy is disabled, the Promise returned by getUserMedia() will reject with a NotAllowedErrorDOMException.
Controls whether or not the current document is permitted to use the getDisplayMedia() method to capture screen contents. When this policy is disabled, the promise returned by getDisplayMedia() will reject with a NotAllowedErrorDOMException if permission is not obtained to capture the display's contents.
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.
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.
Controls whether the current document is allowed to use audio input devices. When this policy is disabled, the Promise returned by MediaDevices.getUserMedia() will reject with a NotAllowedErrorDOMException.
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: ..., ...}).
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.
Controls whether a document loaded in a third-party context (i.e., embedded in an ) is allowed to use the Storage Access API to request access to unpartitioned cookies.
Controls whether or not the current document is allowed to use the Navigator.share() of Web Share API to share text, links, images, and other content to arbitrary destinations of user's choice, e.g., mobile apps.
Several features can be controlled at the same time by sending the header with a comma-separated list of policies, or by sending a separate header for each policy.
For an to have a feature enabled its allowed origin must also be in the allowlist for the parent page. Because of this inheritance behavior, it is a good idea to specify the widest acceptable support for a feature in the HTTP header, and then specify the subset of support you need in each .
To allow all origins access to geolocation, you would do this:
html
To apply a policy to the current origin and others, you'd do this:
html
This is important: By default, if an navigates to another origin, the policy is not applied to the origin that the navigates to. By listing the origin that the navigates to in the allow attribute, the Permissions Policy that was applied to the original will be applied to the origin the navigates to.
Several features can be controlled at the same time by including a semi-colon-separated list of policy directives inside the allow attribute.
html
It is worth giving the src value a special mention. We mentioned above that using this allowlist value will mean that the associated feature will be allowed in this , as long as the document loaded into it comes from the same origin as the URL in its src attribute. This value is the defaultallowlist value for features listed in allow, so the following are equivalent:
SecureCorp Inc. wants to disable Microphone (for example MediaDevices.getUserMedia()) and Geolocation APIs in its application. It can do so using the following response header:
http
Permissions-Policy: microphone=(), geolocation=()
By specifying () for the origin list, the specified features will be disabled for all browsing contexts (this includes all s), regardless of their origin.
For example, let's say that we wanted to enable geolocation usage on our own origin, and in embedded content coming from our trusted ad network. We could set up the page-wide Permissions Policy like this: