Berechtigungspolitik

Das Web bietet Funktionalitäten und APIs, die bei Missbrauch Datenschutz- oder Sicherheitsrisiken darstellen können. In solchen Fällen möchten Sie möglicherweise die Nutzung von Funktionalitäten auf einer Website streng begrenzen. In jedem Fall sollte es eine intuitive oder nicht störende Möglichkeit für Webentwickler geben, Fälle zu erkennen und zu handhaben, in denen eine Funktion deaktiviert ist.

Einige Ansätze umfassen:

• "Permission denied" wird für JavaScript-APIs zurückgegeben, die eine Benutzerberechtigung erfordern.
• JavaScript-APIs, die Zugriff auf Funktionen bieten, geben false-Werte zurück oder werfen einen Fehler.
• APIs werden nicht einmal bereitgestellt, als ob sie nicht existieren würden.
• Optionen, die das Funktionsverhalten steuern, haben unterschiedliche Standardwerte.

Die Berechtigungspolitik ermöglicht es Ihnen, zu kontrollieren, welche Ursprünge welche Funktionen verwenden können, sowohl auf der obersten Seite als auch in eingebetteten <iframe>s. Ziel ist es, bewährte Praktiken für gute Benutzererfahrungen durchzusetzen und eine granulare Kontrolle über sensible oder leistungsstarke Funktionen zu bieten (was bedeutet, dass der Benutzer ausdrücklich die Erlaubnis zur Nutzung erteilen muss, bevor zugehöriger Code ausgeführt werden kann).

Die Berechtigungspolitik bietet zwei Möglichkeiten, Richtlinien festzulegen:

• Der Permissions-Policy HTTP-Header, um die Nutzung von Funktionen in empfangenen Antworten und jeglichen eingebetteten Inhalten innerhalb der Seite zu kontrollieren (dazu gehören <iframe>s).
• Das <iframe> allow-Attribut, um die Nutzung von Funktionen nur in bestimmten <iframe>s zu steuern.

Diese sind getrennt, aber verwandt — siehe Vererbung von Richtlinien für eingebettete Inhalte für Details.

Um jede Funktion zu steuern, schreiben Sie eine Richtlinie, bestehend aus:

• Einer Direktive, die den Namen der zu steuernden Funktion identifiziert. Siehe die Liste der verschiedenen verfügbaren Direktiven.
• Einer Positivliste, die eine Liste von Ursprüngen ist, in denen die Funktion kontrolliert werden soll. Sie können eine Funktion für alle oder spezifische Ursprünge aktivieren oder ihre Nutzung in allen Ursprüngen blockieren.

Siehe unten für mehrere Beispiele.

Die Berechtigungspolitik und die Permissions API sind eng verwandt, aber unterschiedlich. Die Funktionen, deren Berechtigungen von beiden Technologien gesteuert werden, überschneiden sich.

• Die Berechtigungspolitik erlaubt es einem Server festzulegen, ob eine Funktion in einem bestimmten Dokument (oder eingebetteten <frame>s darin) verwendet werden kann. Diese werden als richtliniengesteuerte Funktionen bezeichnet — siehe die Liste der Berechtigungspolitik-Direktiven.
• Die Permissions API regelt den Zugriff auf Funktionen basierend auf vom Benutzer gewährten Berechtigungen. Diese Funktionen sind im Permissions Registry aufgezeichnet.

Der Identifizierungsstring, der für jede Funktion verwendet wird, ist in beiden Konsistent, beispielsweise geolocation für die Geolocation API. Die meisten der API-Funktionen im Permissions Registry haben auch eine entsprechende Berechtigungspolitik-Direktive. Eine Ausnahme bildet die Notifications API.

Im Allgemeinen, wenn eine Berechtigungspolitik die Nutzung einer leistungsstarken Funktion blockiert, wird der Benutzer nicht einmal nach Erlaubnis gefragt, sie zu verwenden, und die Permissions API-Methode query() gibt einen state-Wert denied zurück.

Siehe auch Permissions > Relationship to the Permissions Policy specification.

Eine Positivliste ist eine Liste von Ursprüngen, die einen oder mehrere der folgenden Werte in Klammern enthalten, durch Leerzeichen getrennt:

• *: Die Funktion wird in diesem Dokument und allen verschachtelten Browsing-Kontexten (<iframe>s) unabhängig von ihrem Ursprung erlaubt.
• () (leere Positivliste): Die Funktion ist in obersten und verschachtelten Browsing-Kontexten deaktiviert. Das Äquivalent für das <iframe>-Attribut allow ist 'none'.
• self: Die Funktion wird in diesem Dokument und in allen verschachtelten Browsing-Kontexten (<iframe>s) nur im gleichen Ursprung erlaubt. Die Funktion ist nicht in plattformübergreifenden Dokumenten in verschachtelten Browsing-Kontexten erlaubt. self kann als Abkürzung für https://your-site.example.com betrachtet werden. Das Äquivalent für das <iframe>-Attribut allow ist 'self'.
• 'src': Die Funktion wird in diesem <iframe> erlaubt, solange das geladene Dokument von demselben Ursprung kommt wie die URL in seinem src-Attribut. Dieser Wert wird nur im <iframe>-Attribut allow verwendet und ist der Standardwert der Positivliste 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 sein. Beachten Sie, dass Ursprünge in <iframe>-Attributen nicht in Anführungszeichen gesetzt sind.

Die Werte * und () dürfen nur allein verwendet werden, während self und src in Kombination mit einem oder mehreren Ursprüngen verwendet werden können.

Wo unterstützt, können Sie Platzhalter in Berechtigungspolitik-Ursprüngen einfügen. Das bedeutet, dass Sie anstelle mehrerer verschiedener Subdomains nur einen Platzhalter verwenden müssen.

Anstatt

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

können Sie schreiben

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

Beispiele für Positivlisten:

• *
• ()
• (self)
• (src)
• ("https://a.example.com")
• ("https://a.example.com" "https://b.example.com")
• (self "https://a.example.com" "https://b.example.com")
• (src "https://a.example.com" "https://b.example.com")
• ("https://*.example.com")

Die allgemeine Syntax sieht wie folgt aus:

Permissions-Policy: <directive>=<allowlist>

Um beispielsweise den gesamten Zugriff auf Geolokalisierung zu blockieren, würden Sie dies tun:

Permissions-Policy: geolocation=()

Oder um den Zugriff nur auf eine Teilmenge der Ursprünge zu erlauben, würden Sie dies tun:

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 durch Senden eines separaten Headers für jede Richtlinie.

Zum Beispiel sind die folgenden 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=*

Damit ein <iframe> eine Funktion aktiviert hat, muss dessen erlaubter Ursprung auch in der Positivliste für die übergeordnete Seite enthalten sein. Aufgrund dieses Vererbungsverhaltens ist es eine gute Idee, die weitestgehende unterstützbare Unterstützung für eine Funktion im HTTP-Header anzugeben und dann das benötigte Unterstützungsspektrum in jedem <iframe> anzugeben.

Die allgemeine Syntax sieht wie folgt aus:

<iframe src="<origin>" allow="<directive> <allowlist>"></iframe>

Um beispielsweise den gesamten Zugriff auf Geolokalisierung zu blockieren, würden Sie dies tun:

<iframe src="https://example.com" allow="geolocation 'none'"></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 wird die Richtlinie nicht auf den Ursprung angewendet, zu dem ein <iframe> navigiert, wenn ein <iframe> zu einem anderen Ursprung navigiert. Indem Sie den Ursprung, zu dem das <iframe> navigiert, im Attribut allow auflisten, wird die Berechtigungspolitik, die auf das ursprüngliche <iframe> angewendet wurde, auf den Ursprung angewendet, zu dem das <iframe> navigiert.

Mehrere Funktionen können gleichzeitig gesteuert werden, indem eine durch Semikolons getrennte Liste von Richtliniendirektiven innerhalb des Attributs allow einbezogen wird.

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

Es ist bemerkenswert, den src-Wert besonders zu erwähnen. Wir erwähnten oben, dass die Verwendung dieses Positivlistenwertes bedeutet, dass die zugehörige Funktion in diesem <iframe> erlaubt wird, solange das geladene Dokument von demselben Ursprung wie die URL in seinem src-Attribut stammt. Dieser Wert ist der Standardwert der allowlist für Funktionen, die in allow gelistet sind, so dass die folgenden gleichwertig sind:

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

<fencedframe>s interagieren mit Berechtigungspolitiken auf dieselbe Weise wie <iframe>s, jedoch in einer viel eingeschränkteren Kapazität. Nur bestimmte Funktionen, die für die Verwendung in <fencedframe>s entwickelt wurden, können über Berechtigungspolitiken aktiviert werden; andere richtliniengesteuerte Funktionen sind in diesem Kontext nicht verfügbar.

Siehe Berechtigungspolitiken verfügbar für eingezäunte Frames für weitere Details.

Skripte erben die Richtlinie ihres Browsing-Kontexts, unabhängig von ihrem Ursprung. Das bedeutet, dass die obersten Skripte die Richtlinie des Hauptdokuments erben.

Alle <iframe>s erben die Richtlinie ihrer übergeordneten Seite. Wenn das <iframe> ein allow-Attribut und die übergeordnete Seite einen Permissions-Policy hat, werden die Richtlinien der übergeordneten Seite und das allow-Attribut kombiniert, wobei die restriktivste Teilmenge angewendet wird. Damit ein <iframe> eine Funktion aktiviert hat, muss der Ursprung sowohl in der Positivliste der übergeordneten Seite als auch im allow-Attribut enthalten sein.

Das Deaktivieren einer Funktion in einer Richtlinie ist ein Einwegschalter. Wenn eine Funktion für ein Kind-Frame von seinem Eltern-Frame deaktiviert wurde, kann das Kind sie nicht wieder aktivieren, und weder können es die Nachkommen des Kindes.

Angenommen, wir wollten die Nutzung der Geolokalisierung auf unserem eigenen Ursprung und in eingebetteten Inhalten von unserem vertrauenswürdigen Werbenetzwerk ermöglichen. Wir könnten die seitenweite Berechtigungspolitik 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 so einstellen:

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

• Permissions-Policy HTTP-Header
• allow Attribut für iframes
• Kontrolle von Browser-Funktionen mit Berechtigungspolitik: Leitfaden mit mehreren Demo-Links.
• Permissions/Feature-Richtlinien auf chromestatus.com
• Privatsphäre, Berechtigungen und Informationssicherheit