Was der Permissions-Policy-Header tatsächlich sperren kann

Die Kurzfassung

Permissions-Policy ist ein HTTP-Response-Header, mit dem eine Website den Zugriff auf bestimmte Browserfunktionen begrenzen kann: Kamera, Mikrofon, Geolocation, Fullscreen, Payment, Sensoren und eine lange Liste kleinerer APIs.

Er ist kein allgemeiner Datenschutzschild. Er stoppt nicht jedes Tracking, blockiert keine Cookies, verhindert keine Netzwerkanfragen und macht JavaScript von Drittanbietern nicht sicher. Was er gut kann, ist enger gefasst und trotzdem wertvoll: die Browserfähigkeiten reduzieren, die Ihren eigenen Seiten und eingebetteten Frames zur Verfügung stehen.

Das ist wichtig, weil moderne Websites aus Analytics-Snippets, Media-Embeds, Chat-Widgets, Consent-Managern, Werbeskripten, Karten, Payment-Flows und internen Experimenten zusammengesetzt sind. Die meisten dieser Komponenten benötigen keinen Zugriff auf mächtige Geräte-APIs. Eine gute Policy macht das ausdrücklich.

Wenn Sie bereits Header in Produktion prüfen, kombinieren Sie diese Arbeit mit einer direkten Prüfung der tatsächlichen Response. Unser Leitfaden zum Debuggen von Redirects und HTTP-Headern in Produktion behandelt die Gewohnheit, auf die es hier ankommt: Prüfen Sie, was der Browser wirklich empfängt, nicht was laut Ihrer Konfigurationsdatei passieren sollte.

Was Permissions-Policy kontrolliert

Der Header kontrolliert den Zugriff auf benannte Browserfunktionen. Die genaue Liste ändert sich im Laufe der Zeit, weil sich Browser-APIs ändern, aber gängige Direktiven sind unter anderem:

• camera
• microphone
• geolocation
• fullscreen
• payment
• usb
• bluetooth
• accelerometer
• gyroscope
• magnetometer
• screen-wake-lock
• clipboard-read
• clipboard-write
• publickey-credentials-get
• interest-cohort in älteren Diskussionen, heute größtenteils historisch

Eine Direktive kann eine Funktion für niemanden, für den aktuellen Origin oder für ausgewählte Origins erlauben. Zum Beispiel:

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

Das bedeutet, dass Kamera und Mikrofon für das Dokument und seine verschachtelten Browsing-Kontexte deaktiviert sind, während Geolocation nur für denselben Origin erlaubt ist.

Ein großzügigeres Beispiel:

Permissions-Policy: geolocation=(self "https://maps.example"), fullscreen=(self "https://video.example")

Dies erlaubt Ihrem eigenen Origin und einem benannten Kartenanbieter die Nutzung von Geolocation sowie Ihrem eigenen Origin plus einem Videoanbieter das Anfordern von Fullscreen.

Die Policy wird vom Browser ausgewertet. Wenn eine Funktion nicht erlaubt ist, sollte JavaScript, das diese API verwendet, fehlschlagen oder sich so verhalten, als sei sie nicht verfügbar. Der genaue Fehlermodus hängt von der API ab. Manchmal wird ein Promise abgelehnt. Manchmal erscheint eine Fähigkeit schlicht nicht nutzbar.

Was er auf Ihren eigenen Seiten sperren kann

Auf First-Party-Seiten ist Permissions-Policy vor allem als Leitplanke nützlich. Er reduziert den Wirkungsbereich von versehentlichem oder unerwartetem Code.

Eine Marketingseite benötigt zum Beispiel wahrscheinlich weder Mikrofon noch Kamera, Bluetooth, USB, Bewegungssensoren oder Payment-APIs. Sie können diese Funktionen global verweigern:

Permissions-Policy: camera=(), microphone=(), bluetooth=(), usb=(), payment=(), accelerometer=(), gyroscope=(), magnetometer=()

Das macht nicht jedes Skript auf der Seite vertrauenswürdig. Es bedeutet aber: Wenn ein Tag-Manager-Experiment, eine kompromittierte Dependency oder ein eingefügtes Widget versucht, eine eingeschränkte API aufzurufen, sollte der Browser keinen Zugriff gewähren.

Für Teams mit vielen Mitwirkenden ist das ein nützlicher Standard. Es verlagert die Diskussion von vagem Vertrauen zu expliziten Fähigkeiten. Wenn eine künftige Funktion tatsächlich die Kamera benötigt, muss jemand die Policy ändern und erklären, warum.

Das ist die richtige Art von Reibung.

Was er in iframes sperren kann

Besonders nützlich wird der Header bei eingebetteten Inhalten.

Browser behandeln iframes bereits als separate Browsing-Kontexte, aber eingebettete Inhalte von Drittanbietern können weiterhin mächtige Funktionen anfordern, wenn Policy und iframe-Attribute dies erlauben. Permissions-Policy lässt die übergeordnete Seite eine Obergrenze setzen.

Wenn Ihre Seite zum Beispiel einen Videoplayer, ein Support-Widget und eine Karte einbettet, können Sie vermeiden, jedem Frame Zugriff auf jede Funktion zu geben. Sie könnten Fullscreen nur für den Videoframe erlauben und Geolocation nur für den Kartenframe.

Es gibt zwei Ebenen, die Sie verstehen sollten:

1. Der HTTP-Header Permissions-Policy setzt die Policy für das Dokument.
2. Das iframe-Attribut allow kann bestimmte Funktionen an einen Frame delegieren, aber nur innerhalb dessen, was die übergeordnete Policy erlaubt.

Ein einfaches iframe könnte so aussehen:

<iframe src="https://video.example/embed/123" allow="fullscreen"></iframe>

Wenn Ihr Header Fullscreen vollständig verweigert, kann das iframe-Attribut diese Verweigerung nicht überschreiben. Wenn Ihr Header Fullscreen für diesen Origin erlaubt, kann das iframe-Attribut ihn delegieren.

Diese Hierarchie ist ein Grund, warum sich der Header lohnt. Er gibt Plattform- oder Sicherheitsteams die Möglichkeit, standortweite Grenzen zu setzen, während Produktteams bestimmte Embeds bei Bedarf weiterhin aktivieren können.

Was er nicht sperren kann

Hier überschätzen Teams den Header manchmal.

Permissions-Policy ersetzt keine Content Security Policy. Er entscheidet nicht, welche Skripte geladen werden dürfen. Er hindert ein Skript nicht daran, Daten über das Netzwerk zu senden. Er bereinigt kein HTML. Er verhindert kein XSS. Er blockiert keinen Formular-Spam. Wenn Formularmissbrauch das Problem ist, beginnen Sie mit den Mechanismen, die in warum Ihr Kontaktformular Ihr größtes Spam-Risiko ist beschrieben werden, nicht mit diesem Header.

Er ersetzt auch keine Cookie-Governance. Cookies, Local Storage, Consent, Third-Party-Embeds und Tracking-Schutzmechanismen von Browsern sind separate Themen. Wenn Sie Datenschutzkontrollen umfassend prüfen, verdient die Cookie-Landschaft einen eigenen Durchgang; die praktischen Änderungen werden in was sich 2026 bei Cookies geändert hat und was Sie dagegen tun sollten behandelt.

Am wichtigsten: Permissions-Policy macht JavaScript von Drittanbietern nicht privat. Wenn Sie ein Drittanbieter-Skript in Ihre First-Party-Seite laden, läuft es im Allgemeinen mit den Privilegien Ihrer Seite, vorbehaltlich anderer Browserbeschränkungen und Ihrer Sicherheitsheader. Kamerazugriff zu verweigern ist gut. Es hindert dieses Skript aber nicht daran, DOM-Inhalte zu lesen, Nutzeraktionen zu beobachten oder erlaubte Netzwerkanfragen zu stellen.

Dafür benötigen Sie andere Kontrollen: sorgfältige Anbieterauswahl, CSP, sandboxed iframes, Subresource Integrity, wo anwendbar, Datenminimierung und langweilige, aber notwendige Reviews.

Eine sinnvolle Standard-Policy

Es gibt keinen universellen Header, der zu jeder Website passt, aber die meisten Content- und Marketingseiten können restriktiv beginnen.

Ein vernünftiger erster Ansatz:

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), bluetooth=(), accelerometer=(), gyroscope=(), magnetometer=(), screen-wake-lock=()

Fügen Sie dann nur wieder hinzu, was die Website tatsächlich nutzt.

Zum Beispiel:

• Ein Shop, der die Payment Request API nutzt, benötigt möglicherweise payment=(self).
• Eine Standortsuche benötigt möglicherweise geolocation=(self) oder einen vertrauenswürdigen Karten-Origin.
• Eine Konferenz-App benötigt möglicherweise camera=(self) und microphone=(self).
• Eine videolastige Website benötigt möglicherweise fullscreen=(self "https://trusted-video.example").

Wichtig ist, nicht einfach eine riesige Policy aus einer Checkliste zu kopieren und sie als erledigt zu betrachten. Beginnen Sie mit Ihrem Funktionsinventar. Welche Seiten benötigen welche Browserfähigkeiten? Welche Embeds benötigen Delegation? Welche Funktionen wären überraschend, wenn sie angefordert würden?

Wie Sie bereitstellen, ohne Dinge zu beschädigen

Rollen Sie dies wie jeden anderen Produktions-Header aus: bewusst.

1. Funktionsnutzung inventarisieren

Durchsuchen Sie Ihre Codebasis nach Browser-API-Aufrufen wie getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB und Wake-Lock-APIs.

Prüfen Sie anschließend Third-Party-Embeds. Die Dokumentation für Video-, Karten-, Payment- und Identity-Anbieter nennt häufig erforderliche iframe-allow-Werte.

2. In einer Umgebung mit geringem Risiko beginnen

Fügen Sie in Staging einen restriktiven Header hinzu und testen Sie zentrale Nutzerwege. Achten Sie auf Meldungen in der Browserkonsole. Browser melden häufig, wenn eine Funktion durch permissions policy blockiert wird.

3. Wo nötig seitenspezifische Policies verwenden

Erzwingen Sie keine einzige globale Policy, wenn Ihr Produkt sehr unterschiedliche Seitentypen hat. Ein Blog, ein Checkout, eine Kartenseite und ein Videoraum benötigen wahrscheinlich unterschiedliche Fähigkeiten.

Die meisten Webserver, Frameworks und Edge-Plattformen können Header bedingt nach Pfad setzen. Das ist oft sauberer, als die gesamte Website für eine einzelne Funktion abzuschwächen.

4. Die echte Response verifizieren

Header können von CDNs, Reverse Proxies, App-Servern und Middleware hinzugefügt, überschrieben, dupliziert oder entfernt werden. Prüfen Sie die finale Response in den Browser DevTools oder mit Kommandozeilenwerkzeugen.

Testen Sie außerdem eingebettete Kontexte. Eine korrekt erscheinende Top-Level-Seite garantiert nicht, dass ein iframe die von Ihnen beabsichtigte Delegation erhalten hat.

5. Ausnahmen dokumentieren

Jede erlaubte Funktion sollte einen Owner und einen Grund haben. Das klingt bürokratisch, bis sechs Monate später niemand mehr weiß, warum geolocation für eine Vendor-Domain geöffnet wurde, die auf der Seite gar nicht mehr erscheint.

Häufige Syntaxfehler

Die moderne Header-Syntax ist kompakt, aber leicht geringfügig falsch zu schreiben.

Verwenden Sie leere Klammern, um eine Funktion zu verweigern:

Permissions-Policy: microphone=()

Verwenden Sie self für den aktuellen Origin:

Permissions-Policy: geolocation=(self)

Verwenden Sie in Anführungszeichen gesetzte Origins für bestimmte externe Origins:

Permissions-Policy: fullscreen=(self "https://video.example")

Verlassen Sie sich nicht auf alte Feature-Policy-Beispiele, es sei denn, Sie unterstützen bewusst Legacy-Verhalten. Der ältere Header verwendete eine andere Syntax und ist nicht das, worauf Sie heute Ihre Gestaltung ausrichten sollten.

Denken Sie auch daran, dass die Browserunterstützung je nach Direktive variiert. Ein Browser kann den Header unterstützen, aber eine bestimmte Funktionsdirektive nicht. Das ist normal. Behandeln Sie den Header als Defense-in-Depth-Maßnahme, nicht als Ihre einzige Datenschutz- oder Sicherheitskontrolle.

<!-- tool-cta:start -->

💡 Probieren Sie Folgendes: Überprüfen Sie mit Get Headers, ob Ihre Permissions-Policy wie beabsichtigt ausgeliefert wird, das die rohen Antwort-Header anzeigt, die Ihr Server sendet.

<!-- tool-cta:end -->

Der praktische Datenschutzwert

Der Datenschutzwert von Permissions-Policy besteht nicht darin, dass er eine Website anonym oder trackerfrei macht. Das tut er nicht.

Sein Wert liegt darin, dass er den Zugriff auf sensible Browserfähigkeiten einschränkt. Standort, Kamera, Mikrofon, Gerätesensoren, lokale Hardware-APIs und Payment-Flows sind mächtig. Die meisten Seiten benötigen sie nicht. Viele eingebettete Komponenten sollten sie niemals anfordern können.

Das ist eine echte Verbesserung. Es reduziert versehentliche Prompts, begrenzt unnötige Fähigkeitsfreigaben und gibt Ihrem Team ein konkretes Artefakt, das beim Ausliefern neuer Funktionalität geprüft werden kann.

Die beste Version dieses Headers ist langweilig: standardmäßig restriktiv, nur dort gelockert, wo eine nutzerseitige Funktion es erfordert, und als Teil des normalen Release-Prozesses getestet.