Permissions-Policy
Experimentell: Dies ist eine experimentelle Technologie
Überprüfen Sie die Browser-Kompatibilitätstabelle sorgfältig vor der Verwendung auf produktiven Webseiten.
Der HTTP Permissions-Policy
Antwort-Header bietet einen Mechanismus, um die Nutzung von Browser-Funktionen in einem Dokument oder innerhalb von <iframe>
-Elementen im Dokument zu erlauben oder zu verweigern.
Für weitere Informationen, siehe den Hauptartikel zur Permissions-Policy.
Header-Typ | Antwort-Header |
---|---|
Verbotener Anfrage-Header | ja |
Syntax
Permissions-Policy: <directive>=<allowlist>
<directive>
-
Die Permissions Policy-Direktive, auf die die
allowlist
angewendet werden soll. Siehe Direktiven unten für eine Liste der erlaubten Direktivnamen. <allowlist>
-
Eine Allowlist ist eine Liste von Ursprüngen, die einen oder mehrere der folgenden Werte in Klammern enthält, getrennt durch Leerzeichen:
*
(Wildcard)-
Die Funktion wird in diesem Dokument und allen verschachtelten Browsing-Kontexten (
<iframe>
s) unabhängig von ihrem Ursprung erlaubt. ()
(leere Allowlist)-
Die Funktion ist in obersten und verschachtelten Browsing-Kontexten deaktiviert. Das Äquivalent für
<iframe>
allow
-Attribute ist'none'
. self
-
Die Funktion wird in diesem Dokument und in allen verschachtelten Browsing-Kontexten (
<iframe>
s) mit demselben Ursprung nur erlaubt. Die Funktion ist in dokumentenübergreifenden Kontexten nicht erlaubt.self
kann als Kurzform fürhttps://your-site.example.com
angesehen werden. Das Äquivalent für<iframe>
allow
-Attribute istself
. src
-
Die Funktion wird in diesem
<iframe>
erlaubt, solange das darin geladene Dokument vom selben Ursprung stammt wie die URL in ihrem src-Attribut. Dieser Wert wird nur im<iframe>
allow
-Attribut verwendet und ist der Standardallowlist
-Wert in<iframe>
s. "<origin>"
-
Die Funktion ist für bestimmte Ursprünge erlaubt (zum Beispiel
"https://a.example.com"
). Ursprünge sollten durch Leerzeichen getrennt werden. Beachten Sie, dass Ursprünge in<iframe>
allow-Attributen nicht in Anführungszeichen stehen.
Die Werte
*
und()
dürfen nur allein verwendet werden, währendself
undsrc
in Kombination mit einem oder mehreren Ursprüngen verwendet werden können.Hinweis: Direktiven haben eine Standard-Allowlist, die immer eine der
*
,self
odernone
für denPermissions-Policy
HTTP-Header ist und das Standardverhalten regelt, wenn sie nicht explizit in einer Richtlinie aufgeführt sind. Diese sind auf den einzelnen Direktiven-Referenzseiten angegeben. Für<iframe>
allow
-Attribute ist das Standardverhalten immersrc
.
Wo unterstützt, können Sie Wildcards in Permissions Policy Ursprüngen einfügen. Dies bedeutet, dass Sie statt mehrere verschiedene Subdomains explizit in einer Allowlist anzugeben, sie alle in einem einzigen Ursprung mit einem Wildcard angeben können.
Anstelle von
("https://example.com" "https://a.example.com" "https://b.example.com" "https://c.example.com")
können Sie
("https://example.com" "https://*.example.com")
spezifizieren.
Hinweis: "https://*.example.com"
stimmt nicht mit "https://example.com"
überein.
Direktiven
accelerometer
Experimentell-
Kontrolliert, ob das aktuelle Dokument Informationen über die Beschleunigung des Geräts über die Schnittstelle
Accelerometer
sammeln darf. ambient-light-sensor
Experimentell-
Kontrolliert, ob das aktuelle Dokument Informationen über die Lichtstärke in der Umgebung des Geräts über die Schnittstelle
AmbientLightSensor
sammeln darf. attribution-reporting
Experimentell-
Kontrolliert, ob das aktuelle Dokument die Attribution Reporting API verwenden darf.
autoplay
Experimentell-
Kontrolliert, ob das aktuelle Dokument Medien über die Schnittstelle
HTMLMediaElement
automatisch abspielen darf. Wenn diese Richtlinie deaktiviert ist und es keine Benutzerinteraktionen gab, wird dasPromise
, das vonHTMLMediaElement.play()
zurückgegeben wird, mit einemNotAllowedError
DOMException
abgelehnt. Das Attribut "autoplay" bei<audio>
- und<video>
-Elementen wird ignoriert. bluetooth
Experimentell-
Kontrolliert, ob die Nutzung der Web Bluetooth API erlaubt ist. Wenn diese Richtlinie deaktiviert ist, werden die Methoden des von
Navigator.bluetooth
zurückgegebenenBluetooth
-Objekts entwederfalse
zurückgeben oder das zurückgegebenePromise
mit einemSecurityError
DOMException
ablehnen. browsing-topics
Experimentell Nicht standardisiert-
Regelt den Zugriff auf die Topics API. Falls eine Richtlinie die Nutzung der Topics API verbietet, schlagen alle Versuche, die Methode
Document.browsingTopics()
aufzurufen oder eine Anfrage mit einemSec-Browsing-Topics
-Header zu senden, mit einemNotAllowedError
DOMException
fehl. camera
Experimentell-
Kontrolliert, ob das aktuelle Dokument Videoeingabegeräte verwenden darf. Wenn diese Richtlinie deaktiviert ist, wird das
Promise
, das vongetUserMedia()
zurückgegeben wird, mit einemNotAllowedError
DOMException
abgelehnt. compute-pressure
Experimentell-
Regelt den Zugriff auf die Compute Pressure API.
cross-origin-isolated
Experimentell-
Kontrolliert, ob das aktuelle Dokument als cross-origin isoliert behandelt werden kann.
display-capture
Experimentell-
Kontrolliert, ob das aktuelle Dokument die Methode
getDisplayMedia()
verwenden darf, um Bildschirm-Inhalte zu erfassen. Wenn diese Richtlinie deaktiviert ist, wird das vongetDisplayMedia()
zurückgegebene Promise mit einemNotAllowedError
DOMException
abgelehnt, falls keine Berechtigung zur Erfassung der Bildschirm-Inhalte erteilt wird. document-domain
Experimentell-
Kontrolliert, ob das aktuelle Dokument
document.domain
setzen darf. Wenn diese Richtlinie deaktiviert ist, führt der Versuch,document.domain
zu setzen, zu einemSecurityError
DOMException
. encrypted-media
Experimentell-
Kontrolliert, ob das aktuelle Dokument die Encrypted Media Extensions API (EME) verwenden darf. Wenn diese Richtlinie deaktiviert ist, wird das
Promise
, das vonNavigator.requestMediaKeySystemAccess()
zurückgegeben wird, mit einemSecurityError
DOMException
abgelehnt. fullscreen
Experimentell-
Kontrolliert, ob das aktuelle Dokument
Element.requestFullscreen()
verwenden darf. Wenn diese Richtlinie deaktiviert ist, wird das zurückgegebenePromise
mit einemTypeError
abgelehnt. gamepad
Experimentell-
Kontrolliert, ob das aktuelle Dokument die Gamepad API verwenden darf. Wenn diese Richtlinie deaktiviert ist, werden Aufrufe von
Navigator.getGamepads()
einenSecurityError
DOMException
auslösen, und die Ereignissegamepadconnected
undgamepaddisconnected
werden nicht ausgelöst. geolocation
Experimentell-
Kontrolliert, ob das aktuelle Dokument die
Geolocation
Schnittstelle verwenden darf. Wenn diese Richtlinie deaktiviert ist, führen Aufrufe vongetCurrentPosition()
undwatchPosition()
dazu, dass die Callbacks dieser Funktionen mit einemGeolocationPositionError
Code vonPERMISSION_DENIED
aufgerufen werden. gyroscope
Experimentell-
Kontrolliert, ob das aktuelle Dokument Informationen über die Ausrichtung des Geräts über die Schnittstelle
Gyroscope
sammeln darf. hid
Experimentell-
Kontrolliert, ob das aktuelle Dokument die WebHID API verwenden darf, um eine Verbindung zu unüblichen oder exotischen menschlichen Schnittstellengeräten wie alternativen Tastaturen oder Gamepads herzustellen.
identity-credentials-get
Experimentell-
Kontrolliert, ob das aktuelle Dokument die Verbundene Anmeldeinformation-Verwaltungs-API (Federated Credential Management API, FedCM) verwenden darf, insbesondere die Methode
navigator.credentials.get()
mit eineridentity
-Option. Wo diese Richtlinie die Verwendung der API verbietet, wird dasPromise
, das vomget()
-Aufruf zurückgegeben wird, mit einemNotAllowedError
DOMException
abgelehnt. idle-detection
Experimentell-
Kontrolliert, ob das aktuelle Dokument die Idle Detection API verwenden darf, um zu erkennen, wann Benutzer mit ihren Geräten interagieren, zum Beispiel um einen "verfügbaren"/"abwesenden" Status in Chat-Anwendungen zu melden.
local-fonts
Experimentell-
Kontrolliert, ob das aktuelle Dokument Daten über die lokal installierten Schriftarten des Benutzers über die Methode
Window.queryLocalFonts()
(siehe auch die Local Font Access API) sammeln darf. magnetometer
Experimentell-
Kontrolliert, ob das aktuelle Dokument Informationen über die Ausrichtung des Geräts über die Schnittstelle
Magnetometer
sammeln darf. microphone
Experimentell-
Kontrolliert, ob das aktuelle Dokument Audioeingabegeräte verwenden darf. Wenn diese Richtlinie deaktiviert ist, wird das
Promise
, das vonMediaDevices.getUserMedia()
zurückgegeben wird, mit einemNotAllowedError
DOMException
abgelehnt. midi
Experimentell-
Kontrolliert, ob das aktuelle Dokument die Web MIDI API verwenden darf. Wenn diese Richtlinie deaktiviert ist, wird das
Promise
, das vonNavigator.requestMIDIAccess()
zurückgegeben wird, mit einemSecurityError
DOMException
abgelehnt. otp-credentials
Experimentell-
Kontrolliert, ob das aktuelle Dokument die WebOTP API verwenden darf, um ein einmaliges Passwort (OTP) aus einer speziell formatierten SMS-Nachricht zu beantragen, die vom Server der App gesendet wird, d.h. über
navigator.credentials.get({otp: ..., ...})
. payment
Experimentell-
Kontrolliert, ob das aktuelle Dokument die Payment Request API verwenden darf. Wenn diese Richtlinie aktiviert ist, wird der Konstruktor
PaymentRequest()
einenSecurityError
DOMException
auslösen. picture-in-picture
Experimentell-
Kontrolliert, ob das aktuelle Dokument ein Video über die entsprechende API im Bild-im-Bild-Modus abspielen darf.
publickey-credentials-create
Experimentell-
Kontrolliert, ob das aktuelle Dokument die Web Authentication API verwenden darf, um neue asymmetrische Schlüsselanmeldeinformationen zu erstellen, d.h. über
navigator.credentials.create({publicKey: ..., ...})
. publickey-credentials-get
Experimentell-
Kontrolliert, ob das aktuelle Dokument die Web Authentication API verwenden darf, um bereits gespeicherte öffentliche Schlüsselanmeldeinformationen abzurufen, d.h. über
navigator.credentials.get({publicKey: ..., ...})
. screen-wake-lock
Experimentell-
Kontrolliert, ob das aktuelle Dokument die Screen Wake Lock API verwenden darf, um anzuzeigen, dass das Gerät den Bildschirm nicht ausschalten oder dimmen soll.
serial
Experimentell-
Kontrolliert, ob das aktuelle Dokument die Web Serial API verwenden darf, um mit seriellen Geräten zu kommunizieren, die entweder direkt über einen seriellen Port oder über USB- oder Bluetooth-Geräte verbunden sind, die einen seriellen Port emulieren.
speaker-selection
Experimentell-
Kontrolliert, ob das aktuelle Dokument die Audioausgabegeräte-API verwenden darf, um Lautsprecher aufzulisten und auszuwählen.
storage-access
Experimentell-
Kontrolliert, ob ein Dokument, das in einem Drittkontext (d.h. eingebettet in einem
<iframe>
) geladen wird, die Storage Access API verwenden darf, um den Zugriff auf nicht partitionierte Cookies anzufordern. usb
Experimentell-
Kontrolliert, ob das aktuelle Dokument die WebUSB API verwenden darf.
-
Kontrolliert, ob das aktuelle Dokument die
Navigator.share()
des Web Share API verwenden darf, um Text, Links, Bilder und andere Inhalte an beliebige Ziele aus der Auswahl des Benutzers weiterzugeben, z.B. mobile Apps. window-management
Experimentell-
Kontrolliert, ob das aktuelle Dokument die Window Management API verwenden darf, um Fenster auf mehreren Bildschirmen zu verwalten.
xr-spatial-tracking
Experimentell-
Kontrolliert, ob das aktuelle Dokument die WebXR Device API verwenden darf, um mit einer WebXR-Sitzung zu interagieren.
Beispiele
Grundlegende Nutzung
Permissions-Policy-Header
Um allen Ursprüngen den Zugriff auf die Geolokalisierung zu erlauben, würden Sie dies so tun:
Permissions-Policy: geolocation=*
Oder um den Zugriff auf eine Teilmenge von Ursprüngen zu erlauben, würden Sie dies so tun:
Permissions-Policy: geolocation=(self "https://a.example.com" "https://b.example.com")
Mehrere Funktionen können gleichzeitig kontrolliert werden, indem der Header mit einer kommagetrennten Liste von Richtlinien gesendet wird oder indem ein separater Header für jede Richtlinie gesendet wird.
Zum Beispiel, die folgenden sind gleichwertig:
Permissions-Policy: picture-in-picture=(), geolocation=(self https://example.com/), camera=*
Permissions-Policy: picture-in-picture=()
Permissions-Policy: geolocation=(self https://example.com/)
Permissions-Policy: camera=*
iframes
Damit ein <iframe>
eine Funktion aktiviert hat, muss sein erlaubter Ursprung auch in der Allowlist der übergeordneten Seite enthalten sein. Aufgrund dieses Vererbungverhaltens ist es eine gute Idee, in dem HTTP-Header die weitestgehende akzeptable Unterstützung für eine Funktion festzulegen und dann das benötigte Unterstützungsubset in jedem <iframe>
zu spezifizieren.
Um allen Ursprüngen den Zugriff auf die Geolokalisierung zu erlauben, würden Sie dies so tun:
<iframe src="https://example.com" allow="geolocation *"></iframe>
Um eine Richtlinie auf den aktuellen Ursprung und andere anzuwenden, würden Sie dies tun:
<iframe
src="https://example.com"
allow="geolocation 'self' https://a.example.com https://b.example.com"></iframe>
Dies ist wichtig: Standardmäßig, wenn ein <iframe>
zu einem anderen Ursprung navigiert, wird die Richtlinie nicht auf den Ursprung angewendet, zu dem das <iframe>
navigiert. Indem Sie den Ursprung, zu dem das <iframe>
navigiert, im allow
-Attribut auflisten, wird die auf das ursprüngliche <iframe>
angewendete Permissions-Policy auf den Ursprung angewendet, zu dem das <iframe>
navigiert.
Mehrere Funktionen können gleichzeitig gesteuert werden, indem eine Liste von Richtliniendirektiven, die durch Semikolons getrennt sind, im allow
-Attribut enthalten ist.
<iframe
src="https://example.com"
allow="geolocation 'self' https://a.example.com https://b.example.com; fullscreen 'none'"></iframe>
Es lohnt sich, dem src
-Wert besondere Erwähnung zu schenken. Wir erwähnten oben, dass die Verwendung dieses Allowlist-Wertes bedeutet, dass die damit verbundene Funktion in diesem <iframe>
erlaubt wird, solange das darin geladene Dokument vom selben Ursprung stammt wie die URL in seinem src-Attribut. Dieser Wert ist der Standard allowlist
-Wert für Funktionen, die in allow
aufgeführt sind, daher sind die folgenden gleichwertig:
<iframe src="https://example.com" allow="geolocation 'src'">
<iframe src="https://example.com" allow="geolocation"></iframe
></iframe>
Zugang zu leistungsfähigen Funktionen verweigern
SecureCorp Inc. möchte die Mikrofon- (zum Beispiel MediaDevices.getUserMedia()
) und Geolocation
APIs in seiner Anwendung deaktivieren. Dies kann mit dem folgenden Antwort-Header erreicht werden:
Permissions-Policy: microphone=(), geolocation=()
Durch das Angeben von ()
für die Ursprungs-Liste werden die angegebenen Funktionen für alle Browsing-Kontexte deaktiviert (einschließlich aller <iframe>
s), unabhängig von ihrem Ursprung.
Kombination von HTTP-Header und <iframe>
-Richtlinien
Angenommen, wir möchten die Nutzung von Geolokalisierung auf unserem eigenen Ursprung und in eingebettetem Inhalt von unserem vertrauenswürdigen Werbenetzwerk aktivieren. Wir könnten die seitenweite Permissions-Policy so einrichten:
Permissions-Policy: geolocation=(self https://trusted-ad-network.com)
In unseren Werbe-<iframe>
s könnten wir den Zugriff auf den Ursprung https://trusted-ad-network.com
wie folgt setzen:
<iframe src="https://trusted-ad-network.com" allow="geolocation"></iframe>
Wenn ein anderer Ursprung in das <iframe>
geladen würde, hätte er keinen Zugriff auf die Geolokalisierung:
<iframe src="https://rogue-origin-example.com" allow="geolocation"></iframe>
Spezifikationen
Specification |
---|
Permissions Policy # permissions-policy-http-header-field |
Browser-Kompatibilität
BCD tables only load in the browser