Berechtigungsrichtlinie

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 solcher Funktionen auf einer Website strikt einschränken. 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 Benutzerberechtigungen erfordern.
• JavaScript-APIs, die Zugriff auf Funktionen gewähren, geben false zurück oder werfen einen Fehler.
• APIs werden nicht einmal bereitgestellt, als ob sie nicht existierten.
• Optionen, die das Funktionsverhalten steuern, haben andere Standardwerte.

Die Berechtigungsrichtlinie ermöglicht es Ihnen, zu kontrollieren, welche Ursprünge welche Funktionen nutzen können, sowohl auf der obersten Seite als auch in eingebetteten <iframe>s. Das Ziel ist es, Best Practices für gute Benutzererfahrungen durchzusetzen und eine detaillierte Kontrolle über sensible oder leistungsstarke Funktionen zu bieten (das heißt, Funktionen, für deren Nutzung ein Benutzer eine ausdrückliche Genehmigung erteilen muss, bevor der zugehörige Code ausgeführt werden kann).

Die Berechtigungsrichtlinie bietet zwei Möglichkeiten, Richtlinien zu spezifizieren:

• Der Permissions-Policy HTTP-Header, der die Nutzung von Funktionen in empfangenen Antworten und in allen innerhalb der Seite eingebetteten Inhalten (einschließlich <iframe>s) steuert.
• Das <iframe> allow Attribut, das die Nutzung von Funktionen nur in bestimmten <iframe>s steuert.

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

Um jede Funktion zu kontrollieren, schreiben Sie eine Richtlinie, die besteht aus:

• Einer Direktive, die den Namen der zu kontrollierenden Funktion identifiziert. Siehe die Liste der verschiedenen verfügbaren Direktiven.
• Einer Zulassungsliste, die eine Liste von Ursprüngen enthält, 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 Berechtigungsrichtlinie und die Berechtigungs-API sind eng miteinander verwandt, aber unterschiedlich. Die Funktionen, deren Berechtigungen von beiden Technologien kontrolliert werden, überschneiden sich.

• Die Berechtigungsrichtlinie 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 Berechtigungsrichtliniendirektiven.
• Die Berechtigungs-API regelt den Zugriff auf Funktionen basierend auf von Benutzern erteilten Berechtigungen. Diese Funktionen sind im Berechtigungsregister verzeichnet.

Der Identifikationsstring, der für jede Funktion verwendet wird, ist in beiden gleich, zum Beispiel geolocation für die Geolocation API. Die meisten der API-Funktionen im Berechtigungsregister haben auch eine entsprechende Berechtigungsrichtliniendirektive. Eine Ausnahme ist die Notifications API.

Im Allgemeinen wird der Benutzer nicht einmal um Erlaubnis zur Nutzung einer leistungsstarken Funktion gebeten, wenn eine Berechtigungsrichtlinie deren Nutzung blockiert, und die Methode query() der Berechtigungs-API gibt einen state Wert von denied zurück.

Siehe auch Berechtigungen > Beziehung zur Berechtigungsrichtlinienspezifikation.

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

• *: Die Funktion wird in diesem Dokument und allen verschachtelten Browsing-Kontexten (<iframe>s), unabhängig von ihrem Ursprung, erlaubt.
• () (leere Zulassungsliste): Die Funktion ist in obersten und verschachtelten Browsing-Kontexten deaktiviert. Das Äquivalent für das <iframe> allow Attribut ist 'none'.
• self: Die Funktion wird in diesem Dokument und in allen verschachtelten Browsing-Kontexten (<iframe>s) nur im selben Ursprung erlaubt. Die Funktion ist in Dokumenten mit Cross-Origin in verschachtelten Browsing-Kontexten nicht erlaubt. self kann als Abkürzung 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, solange das darin geladene Dokument vom selben Ursprung stammt wie die URL in seinem src Attribut. Dieser Wert wird nur im <iframe> allow Attribut verwendet und ist der Standard Zulassungswert 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> erlauben 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.

Wo unterstützt, können Sie Platzhalter in Berechtigungsrichtlinienursprüngen verwenden. Dies bedeutet, dass Sie anstelle mehrerer unterschiedlicher Subdomains in einer Zulassungsliste diese alle in einem einzigen Ursprung mit einem Platzhalter angeben können.

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

Zulassungsliste Beispiele:

• *
• ()
• (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 zum Beispiel allen Zugriff auf Geolokalisierung zu blockieren, würden Sie dies so machen:

Permissions-Policy: geolocation=()

Oder um den Zugriff auf eine Teilmenge von Ursprüngen zu erlauben, würden Sie dies so machen:

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 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 sein erlaubter Ursprung auch in der Zulassungsliste für die übergeordnete Seite sein. Aufgrund dieses Vererbungsverhaltens ist es sinnvoll, die breiteste akzeptable Unterstützung für eine Funktion im HTTP-Header anzugeben und dann den benötigten Teil der Unterstützung in jedem <iframe> zu spezifizieren.

Die allgemeine Syntax sieht so aus:

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

Um zum Beispiel allen Zugriff auf Geolokalisierung zu blockieren, würden Sie dies so machen:

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

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

<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 bei einer Navigation eines <iframe> zu einem anderen Ursprung nicht auf den Ursprung angewendet, zu dem das <iframe> navigiert. Durch das Auflisten des Ursprungs, zu dem das <iframe> navigiert, im allow Attribut, wird die auf das ursprüngliche <iframe> angewendete Berechtigungsrichtlinie auf den Ursprung angewendet, zu dem das <iframe> navigiert.

Mehrere Funktionen können gleichzeitig gesteuert werden, indem im allow Attribut eine durch Semikolons getrennte Liste von Richtliniendirektiven eingefügt wird.

<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 eine besondere Erwähnung zu geben. Wir haben oben erwähnt, dass die Verwendung dieses Zulassungslistenwerts bedeuten wird, dass die zugehörige Funktion in diesem <iframe> erlaubt ist, solange das darin geladene Dokument vom gleichen Ursprung stammt wie die URL in seinem src Attribut. Dieser Wert ist der Standard Zulassungslistenwert für Funktionen, die in allow aufgelistet sind, daher sind die folgenden äquivalent:

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

<fencedframe>s interagieren mit Berechtigungsrichtlinien auf dieselbe Weise wie <iframe>s, jedoch in viel eingeschränkterem Umfang. Nur bestimmte Funktionen, die zur Verwendung in <fencedframe>s entworfen wurden, können über Berechtigungsrichtlinien aktiviert werden, die auf ihnen festgelegt sind; andere richtliniengesteuerte Funktionen sind in diesem Kontext nicht verfügbar.

Siehe Berechtigungsrichtlinien für eingezäunte Frames für weitere Details.

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

Das Deaktivieren einer Funktion in einer Richtlinie ist ein Einweg-Schalter. Wenn eine Funktion für ein Kind-Frame von seinem übergeordneten Frame deaktiviert wurde, kann das Kind es nicht erneut aktivieren, und auch keine der Nachkommen des Kindes.

Angenommen, wir wollten die Nutzung von Geolokalisierung auf unserem eigenen Ursprung und in eingebetteten Inhalten, die von unserem vertrauenswürdigen Werbenetzwerk kommen, aktivieren. Wir könnten die seitenweite Berechtigungsrichtlinie 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 letztendlich 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
• Kontrollieren von Browser-Funktionen mit Berechtigungsrichtlinie: Anleitung, die auch mehrere Demos enthält.
• Berechtigungen/Funktionsrichtlinien auf chromestatus.com
• Datenschutz, Berechtigungen und Informationssicherheit