Permissions-Policy header

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

Weitere Informationen finden Sie im Hauptartikel zu Permissions Policy.

Header-Typ	Antwort-Header
Verbotener Request-Header	ja

Syntax

http

Permissions-Policy: <directive>=<allowlist>

<directive>

Die Permissions Policy-Direktive, auf die die allowlist angewendet werden soll. Siehe unten Direktiven 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 enthalten, getrennt durch Leerzeichen:

* (Wildcard): Die Funktion ist in diesem Dokument und allen geschachtelten Browsing-Kontexten (<iframe>s) unabhängig von ihrem Ursprung erlaubt.
() (leere Allowlist): Die Funktion ist in obersten und geschachtelten Browsing-Kontexten deaktiviert. Das Äquivalent für <iframe>-allow-Attribute ist 'none'.
self: Die Funktion ist in diesem Dokument und in allen geschachtelten Browsing-Kontexten (<iframe>s) im gleichen Ursprung erlaubt. Die Funktion ist in fremden Ursprüngen in geschachtelten Browsing-Kontexten nicht erlaubt. self kann als Kurzform für https://ihr-website.beispiel.com betrachtet werden. Das Äquivalent für <iframe>-allow-Attribute ist self.
src: Die Funktion ist in diesem <iframe> erlaubt, solange das Dokument, das darin geladen wird, vom gleichen Ursprung stammt wie die URL im src-Attribut. Dieser Wert wird nur im <iframe>-allow-Attribut verwendet und ist der Standardwert der allowlist in <iframe>s.
"<origin>": Die Funktion ist für bestimmte Ursprünge erlaubt (zum Beispiel "https://a.beispiel.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 alleine verwendet werden, während self und src in Kombination mit einem oder mehreren Ursprüngen verwendet werden können.

Hinweis: Direktiven haben eine Standard-allowlist, die immer einer der Werte *, self oder none für den Permissions-Policy HTTP-Header ist und das Standardverhalten regelt, wenn sie nicht explizit in einer Policy aufgeführt sind. Diese sind auf den einzelnen Direktiven-Referenzseiten angegeben. Für <iframe>-allow-Attribute ist das Standardverhalten immer src.

Wo unterstützt, können Sie Wildcards in Permissions Policy-Ursprüngen einschließen. Dies bedeutet, dass Sie anstelle mehrerer verschiedener Subdomains explizit in einer Allowlist zu spezifizieren, alle in einem einzigen Ursprung mit einem Wildcard angeben können.

Anstatt also

http

("https://example.com" "https://a.example.com" "https://b.example.com" "https://c.example.com")

können Sie angeben

http

("https://example.com" "https://*.example.com")

Hinweis: "https://*.beispiel.com" stimmt nicht mit "https://beispiel.com" überein.

Direktiven

accelerometer Experimentell: Steuert, ob das aktuelle Dokument Informationen über die Beschleunigung des Geräts über die Accelerometer-Schnittstelle sammeln darf.
ambient-light-sensor Experimentell: Steuert, ob das aktuelle Dokument Informationen über die Lichtmenge in der Umgebung des Geräts über die AmbientLightSensor-Schnittstelle sammeln darf.
aria-notify Experimentell Nicht standardisiert: Steuert, ob das aktuelle Dokument die ariaNotify()-Methode verwenden darf, um Screenreader-Benachrichtigungen auszulösen.
attribution-reporting Experimentell: Steuert, ob das aktuelle Dokument die Attribution Reporting API verwenden darf.
autoplay Experimentell: Steuert, ob das aktuelle Dokument Medien, die über die HTMLMediaElement-Schnittstelle angefordert werden, automatisch abspielen darf. Wenn diese Policy deaktiviert ist und es keine Benutzerinteraktionen gab, wird das Promise, das von HTMLMediaElement.play() zurückgegeben wird, mit einem NotAllowedError DOMException abgelehnt. Das Autoplay-Attribut auf <audio> und <video>-Elementen wird ignoriert.
bluetooth Experimentell: Steuert, ob die Nutzung der Web Bluetooth API erlaubt ist. Wenn diese Policy deaktiviert ist, werden die Methoden des Bluetooth-Objekts, das von Navigator.bluetooth zurückgegeben wird, entweder false zurückgeben oder das zurückgegebene Promise mit einem SecurityError DOMException ablehnen.
browsing-topics Experimentell Nicht standardisiert: Steuert den Zugriff auf die Topics API. Wo eine Policy die Nutzung der Topics API ausdrücklich verbietet, werden alle Versuche, die Methode Document.browsingTopics() aufzurufen oder eine Anfrage mit einem Sec-Browsing-Topics-Header zu senden, mit einem NotAllowedError DOMException fehlschlagen.
camera Experimentell: Steuert, ob das aktuelle Dokument Videoeingabegeräte verwenden darf. Das von getUserMedia() zurückgegebene Promise wird mit einem NotAllowedError DOMException abgelehnt, wenn die Erlaubnis nicht erteilt wird.
captured-surface-control Experimentell: Steuert, ob das Dokument die Captured Surface Control API verwenden darf. Das von den Hauptmethoden der API zurückgegebene Versprechen wird mit einem NotAllowedError DOMException abgelehnt, wenn die Erlaubnis nicht erteilt wird.
compute-pressure Experimentell: Steuert den Zugriff auf die Compute Pressure API.
cross-origin-isolated Experimentell: Steuert, ob das aktuelle Dokument als cross-origin isolated behandelt werden kann.
deferred-fetch Experimentell: Steuert die Zuweisung des fetchLater() Kontingents für den obersten Ursprung.
deferred-fetch-minimal Experimentell: Steuert die Zuweisung des gemeinsamen fremden Unterrahmen- fetchLater() Kontingents.
display-capture Experimentell: Steuert, ob das aktuelle Dokument die Methode getDisplayMedia() verwenden darf, um Bildschirm-Inhalte aufzunehmen. Wenn diese Policy deaktiviert ist, wird das von getDisplayMedia() zurückgegebene Versprechen mit einem NotAllowedError DOMException abgelehnt, wenn die Erlaubnis nicht erteilt wird, die Bildschirm-Inhalte aufzunehmen.
encrypted-media Experimentell: Steuert, ob das aktuelle Dokument die Encrypted Media Extensions API (EME) verwenden darf. Wenn diese Policy deaktiviert ist, wird das von Navigator.requestMediaKeySystemAccess() zurückgegebene Promise mit einem SecurityError DOMException abgelehnt.
fullscreen Experimentell: Steuert, ob das aktuelle Dokument Element.requestFullscreen() verwenden darf. Wenn diese Policy deaktiviert ist, wird das zurückgegebene Promise mit einem TypeError abgelehnt.
gamepad Experimentell: Steuert, ob das aktuelle Dokument die Gamepad API verwenden darf. Wenn diese Policy deaktiviert ist, werden Aufrufe von Navigator.getGamepads() einen SecurityError DOMException werfen, und die Ereignisse gamepadconnected und gamepaddisconnected werden nicht ausgelöst.
geolocation Experimentell: Steuert, ob das aktuelle Dokument die Geolocation-Schnittstelle verwenden darf. Wenn diese Policy deaktiviert ist, werden Aufrufe von getCurrentPosition() und watchPosition() dazu führen, dass die Rückrufe dieser Funktionen mit einem GeolocationPositionError-Code von PERMISSION_DENIED aufgerufen werden.
gyroscope Experimentell: Steuert, ob das aktuelle Dokument Informationen über die Ausrichtung des Geräts über die Gyroscope-Schnittstelle sammeln darf.
hid Experimentell: Steuert, ob das aktuelle Dokument die WebHID API zum Anschluss an ungewöhnliche oder exotische Human Interface Devices wie alternative Tastaturen oder Gamepads verwenden darf.
identity-credentials-get Experimentell: Steuert, ob das aktuelle Dokument die Federated Credential Management API (FedCM) verwenden darf.
idle-detection Experimentell: Steuert, ob das aktuelle Dokument die Idle Detection API verwenden darf, um zu erkennen, wann Benutzer mit ihren Geräten interagieren, zum Beispiel, um den Status "verfügbar"/"abwesend" in Chat-Anwendungen zu melden.
language-detector Experimentell: Steuert den Zugriff auf die Spracherkennungsfunktionalität der Übersetzer und Spracherkennungs-APIs.
local-fonts Experimentell: Steuert, ob das aktuelle Dokument Daten zu den lokal installierten Schriftarten des Benutzers über die Methode Window.queryLocalFonts() sammeln darf (siehe auch die Local Font Access API).
magnetometer Experimentell: Steuert, ob das aktuelle Dokument Informationen über die Orientierung des Geräts über die Magnetometer-Schnittstelle sammeln darf.
microphone Experimentell: Steuert, ob das aktuelle Dokument Audioeingabegeräte verwenden darf. Wenn diese Policy deaktiviert ist, wird das von MediaDevices.getUserMedia() zurückgegebene Promise mit einem NotAllowedError DOMException abgelehnt.
midi Experimentell: Steuert, ob das aktuelle Dokument die Web MIDI API verwenden darf. Wenn diese Policy deaktiviert ist, wird das von Navigator.requestMIDIAccess() zurückgegebene Promise mit einem SecurityError DOMException abgelehnt.
on-device-speech-recognition Experimentell: Steuert den Zugriff auf die Sprachverarbeitungsfunktionalität der Web Speech API.
otp-credentials Experimentell: Steuert, ob das aktuelle Dokument die WebOTP API verwenden darf, um ein Einmalpasswort (OTP) aus einer speziell formatierten SMS-Anfrage des Servers der App anzufordern, d.h. über navigator.credentials.get({otp: ..., ...}).
payment Experimentell: Steuert, ob das aktuelle Dokument die Payment Request API verwenden darf. Wenn diese Policy aktiviert ist, wird der Konstruktor PaymentRequest() einen SecurityError DOMException werfen.
picture-in-picture Experimentell: Steuert, ob das aktuelle Dokument erlaubt ist, ein Video im Bild-im-Bild-Modus über die entsprechende API abzuspielen.
publickey-credentials-create Experimentell: Steuert, ob das aktuelle Dokument die Web Authentication API verwenden darf, um neue asymmetrische Schlüsseldaten zu erstellen, d.h. über navigator.credentials.create({publicKey: ..., ...}).
publickey-credentials-get Experimentell: Steuert, ob das aktuelle Dokument die Web Authentication API verwenden darf, um bereits gespeicherte Public-Key-Credentials abzurufen, d.h. über navigator.credentials.get({publicKey: ..., ...}).
screen-wake-lock Experimentell: Steuert, 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: Steuert, ob das aktuelle Dokument die Web Serial API verwenden darf, um mit seriellen Geräten zu kommunizieren, entweder direkt über einen seriellen Anschluss oder über USB- oder Bluetooth-Geräte, die einen seriellen Anschluss emulieren.
speaker-selection Experimentell: Steuert, ob das aktuelle Dokument die Audio Output Devices API verwenden darf, um Lautsprecher aufzulisten und auszuwählen.
storage-access Experimentell: Steuert, ob ein in einem fremden Kontext geladenes Dokument (d.h. eingebettet in ein <iframe>) die Storage Access API verwenden darf, um Zugriff auf nicht partitionierte Cookies anzufordern.
translator Experimentell: Steuert den Zugriff auf die Übersetzungsfunktionalität der Übersetzer und Spracherkennungs-APIs.
summarizer Experimentell: Steuert den Zugriff auf die Summarizer API.
usb Experimentell: Steuert, ob das aktuelle Dokument die WebUSB API verwenden darf.
web-share Experimentell: Steuert, ob das aktuelle Dokument den Navigator.share() der Web Share API verwenden darf, um Text, Links, Bilder und andere Inhalte an beliebige Ziele der Wahl des Benutzers zu teilen, z.B. mobile Apps.
window-management Experimentell: Steuert, ob das aktuelle Dokument die Window Management API verwenden darf, um Fenster auf mehreren Anzeigen zu verwalten.
xr-spatial-tracking Experimentell: Steuert, ob das aktuelle Dokument die WebXR Device API verwenden darf, um mit einer WebXR-Sitzung zu interagieren.

Beispiele

Grundlegende Verwendung

Permissions-Policy-Header

Um allen Ursprüngen Zugang zu Geolocation zu gewähren, würden Sie dies tun:

http

Permissions-Policy: geolocation=*

Oder um den Zugang auf eine Teilmenge von Ursprüngen zu beschränken, würden Sie dies tun:

http

Permissions-Policy: geolocation=(self "https://a.example.com" "https://b.example.com")

Mehrere Funktionen können gleichzeitig gesteuert werden, indem der Header mit einer durch Kommas getrennten Liste von Richtlinien gesendet wird, oder indem für jede Richtlinie ein separater Header gesendet wird.

Zum Beispiel sind die folgenden gleichwertig:

http

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 in einem <iframe> eine Funktion aktiviert ist, muss der erlaubte Ursprung auch in der Allowlist der übergeordneten Seite enthalten sein. Aufgrund dieses Vererbungssverhaltens ist es eine gute Idee, die breiteste akzeptable Unterstützung für eine Funktion im HTTP-Header festzulegen und dann das erforderliche Unterstützungsspektrum in jedem <iframe> zu spezifizieren.

Um allen Ursprüngen Zugang zu Geolocation zu gewähren, würden Sie dies tun:

html

<iframe src="https://example.com" allow="geolocation *"></iframe>

Um eine Richtlinie auf den aktuellen Ursprung und andere anzuwenden, würden Sie dies tun:

html

<iframe
  src="https://example.com"
  allow="geolocation 'self' https://a.example.com https://b.example.com"></iframe>

Dies ist wichtig: Standardmäßig gilt eine Richtlinie nicht für den Ursprung, den das <iframe> durch Navigation erreicht. Durch Auflistung des Ursprungs, zu dem das <iframe> navigiert, im allow-Attribut, wird die ursprünglich auf das <iframe> angewandte Permissions Policy auf den Ursprung angewendet, zu dem das <iframe> navigiert.

Mehrere Funktionen können gleichzeitig gesteuert werden, indem eine durch Semikolons getrennte Liste von Richtlinien-Direktiven im allow-Attribut angegeben wird.

html

<iframe
  src="https://example.com"
  allow="geolocation 'self' https://a.example.com https://b.example.com; fullscreen 'none'"></iframe>

Es ist erwähnenswert, den src-Wert besonders zu erwähnen. Wir haben oben erwähnt, dass die Verwendung dieses Allowlist-Wertes bedeutet, dass die zugehörige Funktion in diesem <iframe> erlaubt wird, solange das darin geladene Dokument vom gleichen Ursprung wie die URL im src-Attribut stammt. Dieser Wert ist der Standard-allowlist-Wert für im allow aufgelistete Funktionen, sodass die folgenden gleichwertig sind:

html

<iframe src="https://example.com" allow="geolocation 'src'"></iframe>
<iframe src="https://example.com" allow="geolocation"></iframe>

Zugriff auf leistungsstarke 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 erfolgen:

http

Permissions-Policy: microphone=(), geolocation=()

Durch die Angabe von () für die Ursprungs-Liste werden die angegebenen Funktionen für alle Browsing-Kontexte (einschließlich aller <iframe>s) unabhängig von ihrem Ursprung deaktiviert.

Kombination von HTTP-Header- und `<iframe>`-Richtlinien

Zum Beispiel, nehmen wir an, dass wir die Nutzung von Geolocation auf unserem eigenen Ursprung und in eingebettetem Inhalt, der von unserem vertrauenswürdigen Werbenetzwerk stammt, aktivieren möchten. Wir könnten die seitenweite Permissions Policy so einrichten:

http

Permissions-Policy: geolocation=(self https://trusted-ad-network.com)

In unseren Werbe-<iframe>s könnten wir den Zugang zum Ursprung https://trusted-ad-network.com wie folgt einrichten:

html

<iframe src="https://trusted-ad-network.com" allow="geolocation"></iframe>

Wenn ein anderer Ursprung schließlich in das <iframe> geladen würde, hätte er keinen Zugang zu Geolocation:

html

<iframe src="https://rogue-origin-example.com" allow="geolocation"></iframe>

Spezifikationen

Specification
Permissions Policy # permissions-policy-http-header-field

Browser-Kompatibilität

Siehe auch

Help improve MDN

Learn how to contribute Diese Seite wurde automatisch aus dem Englischen übersetzt.

Übersetzung auf GitHub anzeigen • Fehler mit dieser Übersetzung melden