Permissions-Policy
Was ist die Permissions-Policy?
Die Permissions-Policy ist ein HTTP-Header, mit dem eine Website Browserfunktionen wie Kamera, Mikrofon, Standortabfrage oder Vollbild gezielt erlaubt, einschränkt oder an eingebettete Inhalte delegiert. Sie schafft damit verbindliche Grenzen für die Nutzung sensibler Web-APIs durch die eigene Seite und durch eingebundene Frames.
Die Permissions-Policy, deutsch einmalig als Berechtigungsrichtlinie bezeichnet, wird vom Server mit der HTTP-Antwort ausgeliefert. Der Browser wertet für jede definierte Funktion eine Allowlist aus. Diese Liste bestimmt, ob die eigene Herkunft, bestimmte externe Ursprünge oder keine Herkunft auf die jeweilige Browserfunktion zugreifen darf.
So funktioniert die Permissions-Policy
Eine Permissions-Policy besteht aus einer oder mehreren Direktiven. Jede Direktive benennt eine Browserfunktion und weist ihr eine Liste erlaubter Ursprünge zu. Der Header Permissions-Policy: geolocation=(self), camera=(), microphone=() erlaubt die Standortabfrage für die eigene Herkunft, sperrt aber Kamera und Mikrofon vollständig.
Die drei wichtigsten Allowlist-Werte haben klar unterschiedliche Wirkungen:
Die Standardregel ist nicht für jede Direktive gleich. Manche Funktionen verwenden ohne eigenen Header standardmäßig self, andere haben weiter oder enger gefasste Voreinstellungen. Eine sichere Konfiguration entsteht deshalb nicht durch das Kopieren einer pauschalen Header-Zeile. Prüfe für jede tatsächlich verwendete Funktion, welche Voreinstellung der Zielbrowser anwendet.
Permissions-Policy: geolocation=(self "https://maps.example"), camera=(), microphone=(). Die eigene Website und der angegebene Kartenanbieter dürfen damit eine Standortabfrage anfordern. Kamera und Mikrofon bleiben für das Hauptdokument und eingebettete Inhalte gesperrt.Permissions-Policy in iFrames
Die Permissions-Policy des Hauptdokuments bildet die obere Grenze für eingebettete Inhalte. Ein allow-Attribut am iFrame kann eine Funktion innerhalb dieser Grenze delegieren oder weiter einschränken. Das Attribut kann jedoch keine Berechtigung herstellen, die der übergeordnete HTTP-Header bereits gesperrt hat.
Ein Video-iFrame kann beispielsweise mit <iframe src="https://video.example" allow="fullscreen; autoplay"> die Funktionen Vollbild und automatische Wiedergabe anfordern. Bei externen iFrames muss die Delegation häufig sowohl im Response Header des Hauptdokuments als auch im allow-Attribut des iFrames vorgesehen sein. Zusätzlich entscheidet der Browser anhand seiner eigenen Regeln, ob eine Nutzerinteraktion erforderlich ist.
Die Permissions-Policy ersetzt keine Zustimmung des Nutzers. Selbst wenn der Header den Zugriff auf Kamera, Mikrofon oder Standort erlaubt, kann der Browser weiterhin eine Freigabe abfragen. Lehnt der Nutzer die Freigabe ab, erhält die Website keinen Zugriff.
Abgrenzung zu ähnlichen Headern
Der Unterschied zwischen Permissions-Policy und Content Security Policy liegt im kontrollierten Gegenstand. Die Permissions-Policy steuert den Zugriff auf Browserfunktionen. Eine Content Security Policy, kurz CSP, legt dagegen fest, aus welchen Quellen Skripte, Bilder, Schriftarten, Frames und andere Ressourcen geladen werden dürfen.
| Mechanismus | Kontrolliert | Typisches Beispiel |
|---|---|---|
| Permissions-Policy | Browserfunktionen und Web-APIs | Kamera, Mikrofon, Standort, Vollbild |
| Content Security Policy | Quellen geladener Ressourcen | Skripte, Bilder, Frames, Verbindungen |
| Permissions API | Status einer Nutzerfreigabe | Erlaubt, verweigert oder noch nicht abgefragt |
iFrame-Attribut allow | Delegation an einen einzelnen Frame | Vollbild für einen Videoplayer |
Die Permissions API ist ebenfalls kein Ersatz für die Permissions-Policy. Die Permissions API fragt im JavaScript-Code ab, welchen Status eine Nutzerfreigabe besitzt. Die Permissions-Policy legt vorher fest, ob das Dokument die betreffende Funktion überhaupt anfordern darf.
Feature-Policy und Permissions-Policy
Die Permissions-Policy ist der Nachfolger der früheren Feature-Policy. Beide Mechanismen verfolgen ein ähnliches Ziel, verwenden aber unterschiedliche Header-Namen und teilweise eine andere Syntax. Eine alte Konfiguration wie Feature-Policy: camera 'none' darf deshalb nicht lediglich in Permissions-Policy umbenannt werden.
Bei einer Migration müssen Header-Syntax, Direktiven und iFrame-Regeln einzeln geprüft werden. Der entsprechende Permissions-Policy-Ausdruck lautet beispielsweise camera=(). Browser können unbekannte oder nicht unterstützte Direktiven ignorieren und eine Meldung in der Entwicklerkonsole ausgeben. Teste die Umstellung daher in allen Browsern, die für deine Nutzer relevant sind.
Relevanz für technisches SEO
Die Permissions-Policy ist kein bekannter direkter Ranking-Faktor. Für technisches SEO wird sie relevant, sobald eine fehlerhafte Regel Inhalte oder Interaktionen blockiert. Ein nicht startender Videoplayer, eine gesperrte Standortfunktion oder ein fehlerhafter Checkout kann Nutzersignale und Conversion beeinträchtigen, obwohl Crawling und Indexierung grundsätzlich funktionieren.
Googlebot benötigt normalerweise keinen Zugriff auf Kamera, Mikrofon oder Standort. Eine restriktive Richtlinie blockiert das Crawling deshalb nicht automatisch. Verwendet eine Website solche Funktionen jedoch für die Darstellung zentraler Inhalte, kann der gerenderte Zustand von dem abweichen, was ein normaler Nutzer nach einer Freigabe sieht. Prüfe solche Seiten zusätzlich mit JavaScript-Rendering und nicht ausschließlich anhand des HTML-Quellcodes.
Für GEO, also Generative Engine Optimization, entsteht ebenfalls kein unmittelbarer Vorteil durch den Header. Technisch stabile, zugängliche Inhalte lassen sich jedoch verlässlicher abrufen und verarbeiten. Informationen, die erst nach einer blockierten Standortabfrage oder innerhalb eines fehlerhaften iFrames erscheinen, stehen Suchmaschinen und KI-Crawlern möglicherweise nicht vollständig zur Verfügung.
Permissions-Policy richtig prüfen
Messbar ist die Permissions-Policy über die Netzwerkdetails des Browsers: Öffne die Entwicklerwerkzeuge, rufe das Dokument neu auf und kontrolliere unter den Response Headers den tatsächlich ausgelieferten Wert. Prüfe anschließend die Browserkonsole auf unbekannte Direktiven, Syntaxfehler und blockierte Funktionen. Ein Eintrag im Server oder CMS reicht nicht aus, weil CDN, Proxy oder Hosting-Konfiguration den Header verändern können.
Für wiederkehrende Audits ergänzt ein Technik-Crawler für technische Website-Prüfungen die manuelle Header-Kontrolle, indem er angrenzende Fehler bei Statuscodes, Ressourcen und Rendering sichtbar macht. Eine breitere Prüfung der technischen Grundlage bietet außerdem ein professionelles SEO-Audit. Den konkreten Permissions-Policy-Header solltest du zusätzlich direkt in der Serverantwort kontrollieren.
Eine belastbare Prüfung folgt einem festen Ablauf:
Die Permissions-Policy sollte nach dem Prinzip der minimal erforderlichen Freigabe aufgebaut sein. Eine Funktion, die keine Seite benötigt, kann vollständig gesperrt werden. Eine benötigte Funktion erhält nur die Ursprünge, die sie tatsächlich verwenden. Weitere Grundlagen zur technischen Optimierung findest du in den wichtigsten technischen SEO-Prüfungen.
Häufige Fragen zur Permissions-Policy
Ist eine Permissions-Policy für jede Website erforderlich?
Eine Permissions-Policy ist keine technische Voraussetzung für den Betrieb einer Website. Der Header ist sinnvoll, wenn du sensible Browserfunktionen begrenzen oder Berechtigungen für eingebettete Inhalte kontrollieren möchtest.
Kann die Permissions-Policy in einem Meta-Tag stehen?
Die Permissions-Policy wird als HTTP Response Header ausgeliefert. Ein Meta-Tag im HTML ist für diesen Mechanismus nicht als gleichwertiger Ersatz vorgesehen.
Warum funktioniert ein iFrame trotz allow-Attribut nicht?
Das allow-Attribut kann nur Funktionen delegieren, die durch die Richtlinie des übergeordneten Dokuments zugelassen sind. Zusätzlich können Browserregeln, Nutzerfreigaben und die Richtlinie des eingebetteten Dokuments den Zugriff begrenzen.
Beeinflusst die Permissions-Policy das Google-Ranking?
Die Permissions-Policy ist kein bekannter direkter Ranking-Faktor. Eine fehlerhafte Konfiguration kann jedoch Inhalte oder Interaktionen blockieren und dadurch Nutzererlebnis, Conversion oder die technische Verarbeitung einer Seite beeinträchtigen.
Welche Funktionen lassen sich mit der Permissions-Policy steuern?
Je nach Browser lassen sich unter anderem Kamera, Mikrofon, Standortabfrage, Vollbild, automatische Wiedergabe und weitere Web-APIs steuern. Die unterstützten Direktiven unterscheiden sich zwischen Browsern und Versionen.
Wie erkenne ich eine fehlerhafte Permissions-Policy?
Kontrolliere den Header in den Netzwerkdetails der Browserwerkzeuge und prüfe die Entwicklerkonsole. Typische Hinweise sind Meldungen zu unbekannten Direktiven, ungültiger Syntax oder blockierten Funktionen.
Wenn du deine Permissions-Policy zusammen mit Crawling, Rendering und weiteren technischen Signalen prüfen lassen möchtest, bietet ein Potenzialcheck eine strukturierte erste Einordnung.
Sie haben noch Fragen?
