Permissions-Policy
Was ist die Permissions-Policy?
Die Permissions-Policy ist ein HTTP-Sicherheitsheader, mit dem eine Website festlegt, welche Browserfunktionen ein Dokument und eingebettete Frames verwenden dürfen. Dazu zählen etwa Kamera, Mikrofon, Standort oder Vollbild. Richtlinien können Funktionen für die eigene Herkunft, ausgewählte Domains oder vollständig sperren und begrenzen so unerwünschte Zugriffe im Browser.
Die Permissions-Policy, auf Deutsch Berechtigungsrichtlinie, steuert den Zugriff einer Website auf ausgewählte Browserfunktionen. Der Browser wertet die Vorgaben aus, bevor ein Dokument oder eingebetteter Inhalt eine geschützte Funktion nutzt. Die Richtlinie wird meist als HTTP-Response-Header vom Webserver ausgeliefert und kann für einzelne Frames zusätzlich über das HTML-Attribut allow festgelegt werden.
Wie funktioniert die Permissions-Policy?
Eine Permissions-Policy besteht aus einer oder mehreren Direktiven. Jede Direktive benennt eine Browserfunktion und enthält eine Herkunftsliste, die den Zugriff erlaubt. Der Header geolocation=(self) gestattet beispielsweise nur Dokumenten derselben Herkunft den Zugriff auf die Standortfunktion. Herkunft bedeutet dabei die Kombination aus Protokoll, Hostname und Port.
Für die Herkunftsliste stehen mehrere grundlegende Werte zur Verfügung:
Permissions-Policy: geolocation=(self), camera=(), microphone=(). Diese Konfiguration erlaubt die Standortabfrage auf der eigenen Herkunft und sperrt Kamera sowie Mikrofon für das gesamte Dokument. Mehrere Direktiven werden im Header durch Kommas getrennt. Die Standardberechtigung unterscheidet sich je nach Browserfunktion. Einige Funktionen sind ohne eigene Richtlinie nur für dieselbe Herkunft freigegeben, andere besitzen eine weiter gefasste Voreinstellung. Eine sichere Konfiguration beginnt deshalb mit einer Bestandsaufnahme: Welche Funktionen benötigt die Website tatsächlich, und welche eingebetteten Dienste müssen darauf zugreifen?
Wichtige Permissions-Policy-Direktiven
Die verfügbaren Direktiven hängen vom Browser und vom Entwicklungsstand der jeweiligen Webplattform-Funktion ab. Besonders relevant sind Funktionen, die auf Geräte, Nutzerdaten oder die Darstellung eingebetteter Inhalte zugreifen. Eine Richtlinie sollte nur Direktiven enthalten, deren Auswirkungen auf der konkreten Website geprüft wurden.
| Direktive | Gesteuerte Funktion | Typischer Anwendungsfall |
|---|---|---|
geolocation | Standort des Nutzers | Filialsuche oder standortbezogene Inhalte |
camera | Zugriff auf die Kamera | Videochat oder Dokumentenerfassung |
microphone | Zugriff auf das Mikrofon | Sprachaufnahme oder Online-Meeting |
fullscreen | Vollbilddarstellung | Videos, Präsentationen oder Anwendungen |
payment | Payment Request API | Browsergestützte Zahlungsvorgänge |
autoplay | Automatische Medienwiedergabe | Videos oder Audioinhalte |
Eine Direktive sperrt nur die zugehörige Browserfunktion. camera=() verhindert beispielsweise den Zugriff auf die Kamera, blockiert aber weder das Laden eines JavaScripts noch die Übertragung anderer Ressourcen. Die Permissions-Policy ist deshalb kein allgemeiner Skriptblocker und kein Werkzeug zur direkten Reduzierung der übertragenen Datenmenge.
Permissions-Policy bei iFrames
Bei einem iFrame wirken die Richtlinie des übergeordneten Dokuments und das allow-Attribut des Frames zusammen. Das übergeordnete Dokument muss die Funktion für die Herkunft des Frames zulassen. Anschließend kann das allow-Attribut den Zugriff innerhalb des Frames weiter begrenzen. Eine bereits durch den HTTP-Header gesperrte Funktion lässt sich im iFrame nicht wieder freigeben.
Ein eingebetteter Kartendienst benötigt beispielsweise möglicherweise die Standortfunktion. Dafür muss die externe Herkunft in der Permissions-Policy des Hauptdokuments zugelassen und dem betreffenden iFrame zugewiesen werden. Die Syntax des HTTP-Headers unterscheidet sich dabei von der Syntax des HTML-Attributs. Eine unveränderte Übernahme zwischen beiden Stellen führt daher regelmäßig zu fehlerhaften Regeln.
Relevanz für technisches SEO
Die Permissions-Policy ist kein bestätigter direkter Ranking-Faktor. Eine fehlerhafte Konfiguration kann jedoch Funktionen blockieren, auf denen sichtbare Inhalte, Formulare, Videos, Karten oder Checkout-Prozesse beruhen. Wenn wichtige Seitenelemente beim Rendering ausfallen, verschlechtern sich Nutzererfahrung und Conversion-Pfade. Prüfe deshalb nicht nur den Header, sondern auch die betroffenen Seitentypen und eingebetteten Inhalte.
Die Permissions-Policy verbessert die Core Web Vitals nicht automatisch. Der Header verhindert normalerweise weder den Download eines Drittanbieter-Skripts noch dessen Ausführung, sondern beschränkt ausgewählte Browser-APIs. Für Ladezeitprobleme bleiben Ressourcenpriorisierung, JavaScript-Umfang, Bildgrößen und Serverantwortzeiten maßgeblich. Solche Faktoren gehören in eine umfassende technische Onpage-Optimierung.
Für SEO und GEO, also Generative Engine Optimization, zählt vor allem die vollständige Auslieferung der relevanten Inhalte. Wenn Text erst nach einer blockierten Browserfunktion erscheint oder ein JavaScript-Fehler die weitere Darstellung unterbricht, können Suchmaschinen und KI-Crawler weniger verwertbare Informationen erhalten. Die Richtlinie sollte daher auch Bestandteil eines technischen SEO-Audits und jeder SEO-Prüfung vor einem Website-Relaunch sein.
Abgrenzung zu anderen Headern
Der Unterschied zwischen Permissions-Policy und Content Security Policy, kurz CSP, liegt im Kontrollgegenstand. Die Permissions-Policy steuert Browserfunktionen wie Kamera oder Standort. Eine CSP legt dagegen fest, aus welchen Quellen beispielsweise Skripte, Bilder, Stylesheets und Frames geladen werden dürfen. Beide Header können parallel eingesetzt werden, ersetzen einander aber nicht.
Der Unterschied zwischen Permissions-Policy und CORS liegt in der Zugriffsebene. Cross-Origin Resource Sharing, kurz CORS, regelt, ob ein Browser Antworten einer anderen Herkunft für JavaScript verfügbar macht. Die Permissions-Policy legt fest, ob ein Dokument eine bestimmte Browserfunktion nutzen darf. Ein korrekt konfiguriertes CORS-Verhalten erteilt daher keine Kamera-, Mikrofon- oder Standortberechtigung.
Feature-Policy ist die frühere Bezeichnung und technische Vorgängerin der Permissions-Policy. Mit der Umbenennung wurde auch die Header-Syntax verändert. Eine alte Konfiguration lässt sich deshalb nicht allein durch das Ersetzen des Header-Namens migrieren. Direktiven, Syntax und Browserunterstützung müssen einzeln geprüft werden.
Permissions-Policy prüfen 2026
Messbar ist die Umsetzung direkt über die HTTP-Antwort und das Verhalten im Browser: Öffne die Entwicklerwerkzeuge, wähle im Netzwerkbereich das Hauptdokument aus und kontrolliere unter den Response Headers den Eintrag Permissions-Policy. Die Browserkonsole und der Bereich für erkannte Probleme zeigen zusätzlich ungültige Direktiven, Syntaxfehler und blockierte Funktionsaufrufe.
Häufige Fragen zur Permissions-Policy
Ist die Permissions-Policy verpflichtend?
Nein, Websites müssen keinen Permissions-Policy-Header ausliefern. Der Header ist eine zusätzliche technische Kontrollschicht, mit der Betreiber Browserfunktionen gezielt begrenzen können. Ob eine Richtlinie sinnvoll ist, hängt von den eingesetzten Funktionen und eingebetteten Diensten ab.
Wo wird die Permissions-Policy eingerichtet?
Die Permissions-Policy wird gewöhnlich als HTTP-Response-Header im Webserver, im Content-Management-System, in der Anwendung oder über eine vorgeschaltete Infrastruktur eingerichtet. Für einzelne iFrames kann zusätzlich das allow-Attribut verwendet werden.
Kann eine Permissions-Policy JavaScript blockieren?
Die Permissions-Policy blockiert JavaScript-Dateien nicht generell. Sie kann einem Skript jedoch den Zugriff auf eine kontrollierte Browserfunktion verweigern. Das Skript wird dann möglicherweise ausgeführt, erhält aber beispielsweise keinen Zugriff auf Kamera oder Standort.
Warum funktioniert ein iFrame trotz allow-Attribut nicht?
Ein allow-Attribut reicht nicht aus, wenn die Funktion bereits durch den HTTP-Header des übergeordneten Dokuments gesperrt wurde. Zusätzlich können eine falsche Herkunft, eine fehlerhafte Syntax oder fehlende Browserunterstützung den Zugriff verhindern.
Ist Feature-Policy noch gültig?
Feature-Policy ist die Vorgängerbezeichnung der Permissions-Policy. Alte Implementierungen können je nach Browser noch teilweise verarbeitet werden, sollten aber nicht als dauerhafte Lösung betrachtet werden. Bei einer Umstellung müssen Header-Name, Direktiven und Syntax geprüft werden.
Beeinflusst die Permissions-Policy das Google-Ranking?
Die Permissions-Policy ist kein bestätigter direkter Ranking-Faktor. SEO-Auswirkungen entstehen indirekt, wenn eine falsche Konfiguration sichtbare Inhalte, Navigationselemente, Videos, Karten oder andere für Nutzer und Rendering relevante Funktionen blockiert.
Wenn du HTTP-Header, Rendering und weitere technische Signale deiner Website systematisch prüfen lassen möchtest, kannst du einen unverbindlichen Potenzialcheck anfragen.
Kostenlosen Potenzialcheck anfragen
Sie haben noch Fragen?
