Permissions Policy: Browserfunktionen für Seite und Einbettungen festlegen

Was Permissions Policy steuert – und was nicht

Browser bieten Webseiten Funktionen an, die über das Anzeigen von Inhalten hinausgehen: Kamera und Mikrofon, Standort, Vollbild, Bildschirmfreigabe, USB-Geräte oder die Payment Request API. Viele davon sind policy-gesteuerte Funktionen (policy-controlled features). Für jede dieser Funktionen legt die jeweilige Spezifikation eine Standard-Allowlist fest. Eine Permissions Policy kann eine Funktion für ein Dokument einschränken und für eingebettete Frames gezielt weitergeben. W3C Permissions Policy: Policy-controlled Features

Zwei Auslieferungswege gehören zusammen:

• Der HTTP-Antwortheader Permissions-Policy gilt für das Dokument, mit dem er ausgeliefert wird. Er begrenzt zugleich, was dieses Dokument an eingebettete Frames weitergeben kann.
• Das Attribut allow an einem iframe legt fest, welche Funktionen der eingebettete Inhalt erhalten soll.

Eine Variante als HTML-meta-Element sieht die Spezifikation nicht vor. W3C: Header- und Container-Policies, W3C: Auslieferung

Ohne Header gilt nicht „alles erlaubt“. Kamera, Mikrofon, Standort, Zahlungsschnittstelle, Bildschirmaufnahme, Vollbild und Autoplay haben die Standard-Allowlist 'self'. Sie stehen dem Dokument im Browserfenster und Frames desselben Origins zur Verfügung; ein Frame mit anderem Origin erhält sie nur, wenn das einbettende Dokument sie mit allow weitergibt. Ein fehlender Header ist deshalb kein Nachweis einer ausnutzbaren Lücke. W3C: Default Allowlists, Media Capture and Streams: camera und microphone, Geolocation API

Die Abgrenzung zur Nutzerberechtigung beschreibt die Permissions-Spezifikation ausdrücklich: Eine Funktion kann nie über Permissions Policy „granted“ werden, sondern nur durch die Zustimmung der Person oder eine Browserregel. W3C Permissions: Verhältnis zu Permissions Policy, W3C: andere und verwandte Mechanismen

Daraus folgt die Sicherheitswirkung: Eine Funktion, die Sie für das gesamte Dokument sperren, etwa mit camera=(), steht auch einem kompromittierten oder eingeschleusten Skript in diesem Dokument nicht zur Verfügung. Funktionen, die Ihre Seite selbst verwendet, bleiben dagegen für jedes Skript nutzbar, das im Kontext Ihres Dokuments läuft. self bezeichnet den Origin des Dokuments, nicht „eigene Skripte“. Gegen eingeschleusten Code helfen andere Maßnahmen wie sichere Ausgabe, Content Security Policy und Subresource Integrity.

Der Web Security Check liest den Permissions-Policy-Header der abgerufenen finalen Antwort, prüft seine Syntax und bewertet für ausgewählte Funktionen wie Kamera, Mikrofon und Standort, ob sie gesperrt oder auf den eigenen Origin begrenzt sind. allow-Attribute, Permissions-Policy-Report-Only, weitere Seiten und das tatsächliche Verhalten eines Browsers erfasst diese Momentaufnahme nicht.

Wie Header und allow zusammenwirken

Jedes Dokument erhält zunächst eine geerbte Policy. Im Browserfenster ergibt sie sich aus den Standard-Allowlists. In einem Frame ergibt sie sich aus der Policy des einbettenden Dokuments und aus dem allow-Attribut des iframe. Der eigene Header eines Dokuments kann Funktionen danach nur weiter einschränken. Was das einbettende Dokument gesperrt hat, kann ein Frame mit einem eigenen Header nicht wieder öffnen. W3C: Inherited policies, W3C: Policy aus der Antwort bilden

Für einen Frame mit anderem Origin gilt bei Funktionen mit Standard-Allowlist 'self': Der Header des einbettenden Dokuments darf den Origin des Frames nicht ausschließen, und das iframe muss die Funktion mit allow weitergeben. Auch das einbettende Dokument selbst muss die Funktion erhalten dürfen; eine Liste nur mit dem fremden Origin reicht nicht. Ein eigener Header des Frames oder eine Sperre weiter oben in der Framekette kann die Funktion zusätzlich verweigern. Diese Bedingungen betreffen die Policy; sichere Kontexte, Nutzerfreigaben und weitere API-Voraussetzungen bleiben bestehen. W3C: Vererbung im Container

Die Browserunterstützung unterscheidet sich stark. Laut den MDN-Kompatibilitätsdaten (Abruf 27.09.2026) wertet Chrome den Header Permissions-Policy seit Version 85 aus; Chromium-basierte Browser wie Edge folgen diesem Stand. Firefox und Safari unterstützen den Header nicht. Das Attribut allow kennen Chrome seit Version 60, Firefox seit 74 und Safari seit 11.1, jeweils mit einer eigenen Liste unterstützter Funktionen. Für Safari verzeichnen die Daten im Attribut etwa camera, microphone und display-capture, nicht aber geolocation oder payment. MDN-Kompatibilitätsdaten: Permissions-Policy, MDN-Kompatibilitätsdaten: iframe allow

Welche Funktionen Sie steuern können

Die folgende Auswahl deckt die häufigsten Fragen ab. Die Arbeitsgruppe führt eine nicht normative Liste standardisierter, vorgeschlagener und experimenteller Funktionen; kein Browser muss jede davon unterstützen. W3C: Feature-Liste zur Spezifikation

Belege für die Standard-Allowlists: Media Capture and Streams, Geolocation, Payment Request, Screen Capture, Fullscreen, HTML: autoplay, WebUSB: Permissions Policy

Die Tabelle ist keine Vorlage. Ob () oder eine Freigabe passt, entscheidet allein, ob Ihr Dokument oder eine Einbettung die Funktion tatsächlich braucht. Sperren Sie etwa autoplay mit autoplay=(self), können eingebettete Videoplayer anderer Origins die Funktion auch mit allow="autoplay" nicht mehr erhalten.

Den Header richtig schreiben

Der Wert von Permissions-Policy ist ein Structured-Field-Dictionary nach RFC 9651. Funktionen werden durch Kommas getrennt, jede Funktion erhält eine Allowlist. Funktionsnamen stehen kleingeschrieben, Origins als Zeichenketten in doppelten Anführungszeichen. W3C: Structured Header Serialization, RFC 9651: Dictionaries

Platzhalter für Unterdomains sind laut MDN-Kompatibilitätsdaten erst seit Chrome 108 unterstützt. Verschiedene Unterdomains und Ports sind verschiedene Origins; https://www.example.com deckt https://shop.example.com nicht ab. W3C: Beispiele

Das folgende Modell passt zu einer Website, die keine der genannten Funktionen selbst nutzt und keiner Einbettung weitergeben muss. Es ist ein Headerbeispiel, keine geprüfte Vorlage für Ihre Anwendung:

Permissions-Policy: camera=(), microphone=(), geolocation=(), display-capture=(), usb=()

Weitere Beobachtungen aus der Probe, die dem Regelwerk entsprechen:

• Unbekannte Funktionsnamen ignoriert der Browser einzeln; die übrigen Einträge gelten weiter.
• Origins ohne Anführungszeichen wie (self http://localhost:PORT) verwarf Chromium als ungültigen Eintrag mit Konsolenwarnung. Der Frame erhielt die Funktion nicht.
• none ist kein Header-Schlüsselwort. Chromium meldete geolocation=none als ungültig und behandelte die Allowlist als leer. Schreiben Sie für eine Sperre ().
• Mehrere Headerzeilen werden zu einer Liste zusammengeführt. Nennen zwei Zeilen dieselbe Funktion, gilt der zuletzt stehende Wert. Setzen Anwendung und CDN beide den Header, entscheidet also die Reihenfolge in der ausgelieferten Antwort. RFC 9651: Dictionaries parsen

Das allow-Attribut verwendet eine andere Schreibweise: Semikolons trennen die Funktionen, Schlüsselwörter stehen in einfachen Anführungszeichen, Origins ohne Anführungszeichen. Ohne Allowlist gilt 'src', also der Origin der URL im src-Attribut. W3C: HTML-Attribut-Serialisierung, W3C: allow-Attribut

<iframe src="https://maps.example.com/embed" allow="geolocation"></iframe>
<iframe src="https://video.example.net/room" allow="camera; microphone; display-capture"></iframe>

Permissions Policy in vier Schritten einführen

1. Genutzte Funktionen und Einbettungen erfassen

Erfassen Sie, welche Funktionen Ihre eigenen Seiten verwenden und welche eingebetteten Dienste welche Funktionen brauchen: Karten, Videoplayer, Videokonferenz, Zahlungsdienste, Chat- oder Supportwerkzeuge, Anmelde- und Identitätsdienste sowie Erweiterungen in CMS und Shopsystemen. Notieren Sie für jede Einbettung den genauen Origin einschließlich Unterdomain und Port.

Legen Sie außerdem fest, welche zuständige Ausgabestelle den Header setzt: Anwendung, Webserver, Reverse Proxy oder CDN. Zwei Stellen, die unabhängig voneinander Werte hinzufügen, führen leicht zu widersprüchlichen Einträgen. Der Artikel zu Implementierung und Architektur behandelt diese Zuständigkeiten. Permissions Policy gilt je Dokument: Soll dieselbe Begrenzung auf allen Seiten gelten, muss sie auch mit Anmelde-, Checkout- und Fehlerdokumenten ausgeliefert werden.

2. Neue Sperren zuerst beobachten

In Chromium-basierten Browsern können Sie Regeln mit Permissions-Policy-Report-Only zunächst beobachten. Laut MDN-Kompatibilitätsdaten ist dieser Header seit Chrome 120 verfügbar; Firefox und Safari unterstützen ihn nicht. In der lokalen Probe blieb die Standortabfrage unter Permissions-Policy-Report-Only: geolocation=() erlaubt; der Browser erzeugte einen Bericht mit der Kennzeichnung report. W3C: Report-Only-Header, MDN-Kompatibilitätsdaten: Report-Only

Reporting-Endpoints: pp-endpoint="https://reports.example.com/permissions-policy"
Permissions-Policy-Report-Only: camera=();report-to=pp-endpoint, microphone=();report-to=pp-endpoint, geolocation=();report-to=pp-endpoint

https://reports.example.com/permissions-policy ist ein Platzhalter für einen Empfänger, den Sie selbst betreiben; der Header richtet keinen ein. Berichte können bei einem Nutzungsversuch entstehen; die Spezifikation sieht außerdem Berichte über mögliche Konflikte zwischen Frame-Freigabe und geerbter Policy vor. Eine Report-Only-Policy setzt parallel bestehende Sperren nicht außer Kraft. Ausbleibende Berichte beweisen daher nicht, dass keine Seite und keine Einbettung die Funktion braucht. Wie Berichte zugestellt und ausgewertet werden, erklärt der Ratgeber zur Reporting API. W3C: Reporting

3. Nicht benötigte Funktionen sperren und benötigte gezielt freigeben

Die folgenden Ausschnitte zeigen die Konfigurationsform für nginx und Apache. Sie sind nicht ausgeführt und setzen voraus, dass Ihre Seiten die genannten Funktionen nicht brauchen.

nginx: add_header wirkt im Kontext http, server oder location. Solche Direktiven werden nur geerbt, wenn auf der aktuellen Ebene keine eigene add_header-Direktive steht; seit nginx 1.29.3 lässt sich das mit add_header_inherit ändern. Ohne always fügt nginx den Header nur bei bestimmten Statuscodes wie 200 oder 301 hinzu. Nach der Änderung ist ein erfolgreicher Reload nötig. nginx: add_header

add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=()" always;

Apache: Der Ausschnitt setzt mod_headers voraus; in .htaccess muss die Konfiguration erlaubt sein, etwa über AllowOverride FileInfo. Ohne geladenes Modul überspringt Apache den Inhalt von IfModule stillschweigend. always und die Standardtabelle onsuccess sind getrennte Headerlisten; ein Header aus einem Backend kann dadurch doppelt ankommen. Apache: Header-Direktive

<IfModule mod_headers.c>
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=()"
</IfModule>

payment=() passt nur, wenn weder Ihre Seite noch ein eingebetteter Zahlungsdienst die Payment Request API nutzt. Braucht eine Einbettung eine Funktion, geben Sie sie an beiden Stellen frei. Im folgenden Modell erhält nur der Videodienst Kamera und Mikrofon:

Permissions-Policy: camera=(self "https://video.example.net"), microphone=(self "https://video.example.net"), geolocation=()

<iframe src="https://video.example.net/room/123" allow="camera; microphone"></iframe>

https://video.example.net steht für den tatsächlichen Origin des eingebetteten Dienstes. Leitet der Dienst den Frame auf einen anderen Origin weiter, gilt die Freigabe dort nicht automatisch.

4. Wirkung prüfen und einen Rückweg bereithalten

Prüfen Sie zuerst, welcher Header tatsächlich ankommt. Für eine berechtigte eigene Adresse zeigt der folgende Aufruf die Header jeder Antwort in einer Weiterleitungskette; der letzte Block gehört zur finalen Antwort:

curl -sS -L -D - -o /dev/null https://www.example.com/

https://www.example.com/ ist ein Platzhalter; der Aufruf wurde nicht gegen eine echte Website ausgeführt. Er zeigt eine einzelne Antwort und kein Browserverhalten.

Im Browser meldet Chromium Verstöße in der Konsole, etwa „Permissions policy violation: Geolocation access has been blocked …“, und nennt Parsefehler des Headers. Chromium stellt die Abfrage der wirksamen Policy unter dem älteren Namen document.featurePolicy bereit, zum Beispiel document.featurePolicy.allowsFeature('camera'). Die Spezifikation nennt die Schnittstelle document.permissionsPolicy; in Chromium 141 war dieser Name in der Probe nicht vorhanden. Testen Sie benötigte Einbettungen zusätzlich in Firefox und Safari, weil dort nur das allow-Attribut und die eigenen Standardregeln wirken. W3C: Policy-Introspektion

Die Rücknahme ist einfacher als bei HSTS: Browser speichern eine Permissions Policy nicht über das Dokument hinaus. Entfernen oder lockern Sie den Header an der zuständigen Ausgabestelle, gilt das für neu geladene Dokumente. Zwischengespeicherte HTML-Antworten in einem CDN, im Browsercache oder in einem Service Worker können den alten Header aber weiter ausliefern, bis sie erneuert werden. Planen Sie deshalb gegebenenfalls ein Leeren der Caches ein. Der Ratgeber zu Cache-Control erklärt die Zwischenspeicher.

Befunde richtig einordnen

Ein fehlender Header zeigt nur, dass für dieses Dokument die Standardregeln des jeweiligen Browsers gelten. Ein vorhandener Header zeigt, welche Regeln ein unterstützender Browser für diese Antwort anwenden kann. Keine der beiden Beobachtungen ist ein Nachweis für oder gegen eine ausnutzbare Lücke.

Ein Befund des Web Security Check bezieht sich auf den Header einer einzelnen abgerufenen Antwort zum Zeitpunkt des Abrufs. Ob Einbettungen funktionieren und welche Funktionen im Browser tatsächlich verfügbar sind, klären erst die Browserprüfungen aus Schritt 4.

Von Feature-Policy umstellen

Permissions Policy hieß früher Feature Policy. Der alte Header Feature-Policy hat eine andere Schreibweise und gilt als veraltet. Laut MDN-Kompatibilitätsdaten verarbeitet Chrome ihn seit Version 60 weiterhin; Firefox und Safari werten ihn nicht aus. W3C: Einführung, MDN-Kompatibilitätsdaten: Feature-Policy

In der lokalen Probe mit Chromium 147 sperrte Feature-Policy: geolocation 'none' allein die Standortabfrage weiterhin. Standen beide Header in der Antwort, galt je Funktion der Wert aus Permissions-Policy; die Konsole meldete die Doppelung. Eine Funktion, die nur im alten Header stand, blieb gesperrt. Chrome beschreibt Feature-Policy als Alias mit niedrigerer Priorität. Chrome for Developers: Permissions Policy

Beachten Sie bei der Umstellung eine Verhaltensänderung: Unter Feature Policy konnte ein Origin in der Header-Liste genügen, um einem fremden Frame eine Funktion zu geben. Unter Permissions Policy braucht der Frame zusätzlich allow. Übersetzen Sie den alten Header, testen Sie betroffene Einbettungen und entfernen Sie Feature-Policy anschließend. Weitere veraltete Header behandelt der Ratgeber zu erweiterten Headern.

Nachweis und Einordnung

Permissions Policy ist eine technische Maßnahme, die ausgewählte Browserfunktionen begrenzt. Ein vorhandener Header ist weder eine allgemeine gesetzliche Pflicht noch ein Konformitätsnachweis. Wenn Sie die Maßnahme dokumentieren, halten Sie geprüfte URL, Zeitpunkt, ausgelieferten Header, betroffene Einbettungen und getestete Browser fest.

Datenschutzrechtliche Grundsätze wie Datenminimierung und datenschutzfreundliche Voreinstellungen (Art. 5 und 25 DSGVO, BfDI-Gesetzessammlung) betreffen die gesamte Verarbeitung. Eine gesperrte Geräteschnittstelle kann dazu beitragen, ersetzt aber keine Bewertung der Verarbeitung. Für Einrichtungen im Anwendungsbereich des BSIG verlangt § 30 geeignete Risikomanagementmaßnahmen; welche Header dazu gehören, ergibt sich aus der eigenen Risikobewertung, nicht aus dem Gesetz. Permissions Policy ist außerdem kein Skriptinventar und keine Prüfung des Inhalts eingebundener Skripte. Die Compliance-Übersicht und die NIS2-Checkliste ordnen diese Bezüge ein.

Weiterführende Themen

Wenn Sie zunächst sehen möchten, welchen Header eine öffentlich erreichbare Seite ausliefert, öffnen Sie den Web Security Check. Er wertet eine einzelne Antwort aus; die oben beschriebenen Tests von Einbettungen und Browsern ersetzt er nicht.