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 strikt begrenzen, wie Funktionen auf einer Website verwendet werden. In jedem Fall sollte es für Webentwickler eine intuitive oder nicht unterbrechende Möglichkeit geben, Fälle zu erkennen und zu handhaben, in denen eine Funktion deaktiviert ist.

Einige Ansätze umfassen:

• "Berechtigung verweigert" wird für JavaScript-APIs zurückgegeben, die Benutzerberechtigungen erfordern.
• JavaScript-APIs, die Zugang zu Funktionen gewähren, geben false Werte zurück oder werfen einen Fehler.
• APIs werden überhaupt nicht bereitgestellt, als ob sie nicht existieren.
• Optionen, die das Funktionsverhalten steuern, haben unterschiedliche Standardwerte.

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

Die Berechtigungspolitik bietet zwei Möglichkeiten, Richtlinien anzugeben:

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

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

Um jede Funktion zu steuern, schreiben Sie eine Richtlinie, die Folgendes umfasst:

• Eine Direktive, die den Namen der zu kontrollierenden Funktion angibt. Siehe die Liste der verschiedenen verfügbaren Direktiven.
• Eine Zulassungsliste, eine Liste von Ursprüngen, in denen die Funktion kontrolliert werden soll. Sie können eine Funktion für alle oder bestimmte Ursprünge aktivieren oder ihre Nutzung in allen Ursprüngen blockieren.

Siehe unten für mehrere Beispiele.

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

• Die Berechtigungspolitik ermöglicht 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 Berechtigungs-API steuert den Zugriff auf Funktionen basierend auf benutzergewährten Berechtigungen. Diese Funktionen sind im Berechtigungsregister aufgezeichnet.

Der Identifizierungsstring, der für jede Funktion verwendet wird, bleibt über beide Technologien hinweg konsistent, z. B. geolocation für die Geolocation API. Die meisten der API-Funktionen im Berechtigungsregister haben auch eine entsprechende Berechtigungspolitik-Direktive. Eine Ausnahme ist die Notifications API.

Grundsätzlich wird der Benutzer nicht einmal um Erlaubnis zur Nutzung einer leistungsstarken Funktion gebeten, wenn eine Berechtigungspolitik ihre Verwendung blockiert, und die Berechtigungs-API-Methode query() gibt einen state Wert von denied zurück.

Siehe auch Berechtigungen > Beziehung zur Berechtigungspolitik-Spezifikation.

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

• *: Die Funktion wird in diesem Dokument und allen verschachtelten Browsing-Kontexten (<iframe>s), unabhängig von ihrer Herkunft, erlaubt sein.
• () (leere Zulassungsliste): Die Funktion ist in obersten und verschachtelten Browsing-Kontexten deaktiviert. Das Äquivalent für <iframe> allow Attribut ist 'none'.
• self: Die Funktion wird in diesem Dokument und in allen verschachtelten Browsing-Kontexten (<iframe>s) mit derselben Herkunft nur erlaubt sein. Die Funktion wird in ursprungsübergreifenden Dokumenten in verschachtelten Browsing-Kontexten nicht erlaubt. self kann als Kurzform für https://your-site.example.com betrachtet werden. Das Äquivalent für das <iframe> allow Attribut ist 'self'.
• 'src': Die Funktion wird in diesem <iframe> erlaubt sein, solange das darin geladene Dokument von derselben Herkunft wie die URL in seinem src Attribut stammt. Dieser Wert wird nur im <iframe> allow Attribut verwendet und ist der standardmäßige Wert der Zulassungsliste für <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 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 verwenden. Das bedeutet, dass Sie anstelle mehrerer unterschiedlicher Subdomains in einer Zulassungsliste explizit anzugeben, alle in einem einzigen Ursprung mit einem Platzhalter spezifizieren können.

Also anstelle von

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

können Sie angeben

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

Beispiele für Zulassungslisten:

• *
• ()
• (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 so aus:

Permissions-Policy: <directive>=<allowlist>

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

Permissions-Policy: geolocation=()

Um den Zugriff auf eine Teilmenge von Ursprüngen zu ermöglichen, 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 Komma-separierten Liste von Richtlinien gesendet wird, oder indem ein separater Header für jede Richtlinie gesendet wird.

Zum Beispiel sind die folgenden äquivalent:

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 der erlaubte Ursprung auch in der Zulassungsliste der übergeordneten Seite enthalten sein. Aufgrund dieses Vererbungverhaltens ist es eine gute Idee, den breitestmöglichen akzeptablen Support für eine Funktion im HTTP-Header anzugeben und dann den erforderlichen Teil-Support in jedem <iframe> anzugeben.

Die allgemeine Syntax sieht so aus:

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

Um also beispielsweise den gesamten Zugriff auf die 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, wenn ein <iframe> zu einem anderen Ursprung navigiert, die Richtlinie nicht auf den Ursprung angewendet, zu dem das <iframe> navigiert. Durch die Auflistung des Ursprungs, zu dem das <iframe> navigiert, im allow Attribut 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 Semikolon getrennte Liste von Richtlinien-Direktiven im allow Attribut eingeschlossen wird.

<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 gesondert zu erwähnen. Wir haben oben erwähnt, dass die Verwendung dieses Wertes der Zulassungsliste bedeutet, dass die zugehörige Funktion in diesem <iframe> erlaubt wird, solange das Dokument, das darin geladen wird, von derselben Herkunft wie die URL in seinem src Attribut ist. Dieser Wert ist der standardmäßige Allowlist-Wert für Funktionen, die in allow aufgeführt sind, so dass die folgenden äquivalent sind:

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

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

Weitere Informationen finden Sie unter Berechtigungspolitiken verfügbar für umzäunte Frames.

Skripte erben die Richtlinie ihres Browsing-Kontextes, unabhängig von ihrem Ursprung. Das bedeutet, dass Top-Level-Skripte die Richtlinie vom Hauptdokument 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 des allow Attributs kombiniert, wobei das restriktivste Teilset verwendet wird. Damit ein <iframe> eine aktivierte Funktion hat, muss der Ursprung sowohl in der Zulassungsliste der übergeordneten Seite als auch im allow Attribut enthalten sein.

Das Deaktivieren einer Funktion in einer Richtlinie ist ein Einweg-Schalter. Wenn eine Funktion für einen untergeordneten Frame durch ihren übergeordneten Frame deaktiviert wurde, kann das Kind sie nicht wieder aktivieren, und auch keine der Nachkommen des Kindes.

Angenommen, wir möchten die Nutzung der Geolokalisierung auf unserem eigenen Ursprung und in eingebetteten Inhalten, die von unserem vertrauenswürdigen Werbenetzwerk kommen, 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 einrichten:

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

Wenn ein anderer Ursprung im <iframe> geladen würde, hätte er keinen Zugang zur Geolokalisierung:

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

• Permissions-Policy HTTP-Header
• allow Attribut bei iframes
• Steuern von Browser-Funktionen mit der Berechtigungspolitik: Anleitung zur Nutzung, die auch mehrere Demo-Links enthält.
• Berechtigungs-/Funktionsrichtlinien auf chromestatus.com
• Datenschutz, Berechtigungen und Informationssicherheit