Der Permissions-Policy-Header im Detail

1. Warum Browser-Feature-Kontrolle Teil der Sicherheitsstrategie ist

Moderne Browser stellen Webseiten eine wachsende Zahl mächtiger APIs zur Verfügung: Zugriff auf Kamera und Mikrofon, Standortermittlung, Vibration, Bewegungssensoren oder das Payment-Request-API. Jede dieser Schnittstellen kann für legitime Anwendungsfälle sinnvoll sein, etwa eine Videokonferenz-Funktion oder ein Store-Locator mit Geolocation, birgt aber auch Missbrauchspotenzial, wenn eingeschleuster Drittanbieter-Code, ein kompromittiertes Werbe-Skript oder ein bösartiges eingebettetes iframe diese Schnittstellen ohne Wissen des Seitenbetreibers anspricht.

Der Permissions-Policy-Header schließt genau diese Lücke, indem er auf HTTP-Ebene festlegt, welche Browser-Features für ein Dokument und alle darin eingebetteten iframes überhaupt zur Verfügung stehen, unabhängig davon, ob einzelner JavaScript-Code versucht, sie anzusprechen. Fehlt der Header, entscheidet allein die Same-Origin-Policy und das Verhalten einzelner iframes darüber, welche Schnittstellen erreichbar sind, was im Zweifel deutlich großzügiger ausfällt als nötig.

2. Syntax und Grundlagen des Permissions-Policy-Headers

Der Header folgt der Structured-Field-Syntax und listet für jede Direktive eine Allowlist von Ursprüngen auf, die das jeweilige Feature nutzen dürfen. Zwei runde Klammern ohne Inhalt bedeuten, dass niemand das Feature nutzen darf, auch nicht die eigene Seite. Das Schlüsselwort self erlaubt es nur dem eigenen Ursprung, während konkrete Domains in Anführungszeichen zusätzliche, vertrauenswürdige Drittanbieter freischalten, etwa ein eingebettetes Video-Widget.

Mehrere Direktiven werden durch Kommas getrennt in einem einzigen Header-Wert zusammengefasst. Fehlt eine Direktive komplett, greift der jeweilige Standardwert der Browser-Spezifikation, der je nach Feature unterschiedlich großzügig ausfällt. Deshalb empfiehlt es sich, sicherheitsrelevante Features immer explizit zu benennen, statt sich auf Browser-Standardwerte zu verlassen, die sich zwischen Chrome, Firefox und Safari durchaus unterscheiden können.

Permissions-Policy: camera=(), microphone=(), geolocation=(self),
  payment=(), usb=(), xr-spatial-tracking=(), fullscreen=(self),
  autoplay=(self), picture-in-picture=(self)

3. Von Feature-Policy zu Permissions-Policy: Was sich geändert hat

Feature-Policy war der historische Vorgänger und wurde bereits um 2018 in Browsern eingeführt, mit einer syntaktisch anderen Schreibweise: Ursprünge standen dort in Anführungszeichen und durch Leerzeichen getrennt, etwa camera 'self' https://beispiel.de. Permissions-Policy löst Feature-Policy ab, nutzt die modernere Structured-Field-Syntax mit Klammern und ist in aktuellen Browsern der maßgebliche Standard, während Feature-Policy in vielen Browsern inzwischen entfernt oder nur noch als Alias behandelt wird.

Wer alte Dokumentation oder Codebeispiele mit Feature-Policy-Syntax findet, sollte diese nicht unverändert übernehmen, weil moderne Browser den Header schlicht ignorieren, wenn die Syntax nicht der aktuellen Spezifikation entspricht. Für maximale Kompatibilität mit älteren Browser-Versionen kann es sinnvoll sein, während einer Uebergangsphase beide Header parallel zu senden, wobei der Fokus klar auf Permissions-Policy liegen sollte, da Feature-Policy als veraltet gilt.

4. Verfügbare Direktiven im Ueberblick

Die Spezifikation definiert eine wachsende Liste von Direktiven, darunter camera, microphone, geolocation, payment, usb, midi, magnetometer, gyroscope, accelerometer, fullscreen, autoplay, encrypted-media, picture-in-picture und xr-spatial-tracking. Jede Direktive steuert genau ein Browser-Feature, und nicht jede API wird von jedem Browser gleichermaßen unterstützt, weshalb ein Blick in aktuelle Kompatibilitätstabellen vor dem produktiven Einsatz sinnvoll ist.

Für die meisten klassischen Webshops ist die überwiegende Mehrheit dieser Features schlicht überflüssig. Ein Shop ohne eigene Videokonferenz-Funktion, ohne In-Browser-Zahlungsintegration über das Payment-Request-API und ohne AR-Produktvorschau benötigt weder camera noch usb noch xr-spatial-tracking, und sollte diese Features konsequent deaktivieren, um die Angriffsfläche zu minimieren, selbst wenn aktuell kein konkreter Missbrauchsfall bekannt ist.

5. Iframes einschränken: Wie der Header als Obergrenze wirkt

Besonders wichtig ist das Zusammenspiel mit eingebetteten iframes, etwa von Zahlungsanbietern, Werbenetzwerken oder Video-Plattformen. Der Permissions-Policy-Header des Hauptdokuments wirkt als Obergrenze: Selbst wenn ein iframe über sein eigenes allow-Attribut ausdrücklich camera oder microphone anfordert, bleibt der Zugriff verweigert, solange die übergeordnete Seite dieses Feature per Header nicht zumindest für die Domain des iframes freigegeben hat.

Diese doppelte Kontrollebene, Header auf Dokumentebene plus allow-Attribut auf iframe-Ebene, verhindert, dass ein eingebettetes Drittanbieter-Skript eigenmächtig Zugriff auf sensible Schnittstellen erlangt, selbst wenn es versucht, sein eigenes iframe-Tag entsprechend zu manipulieren. Seitenbetreiber sollten deshalb für jedes eingebundene Drittanbieter-iframe genau prüfen, welche Features tatsächlich benötigt werden, und nur diese gezielt für die jeweilige Domain freischalten.

6. Unterschied zu Content-Security-Policy: Zwei komplementäre Header

Permissions-Policy wird häufig mit der Content-Security-Policy verwechselt, obwohl beide unterschiedliche Aufgaben erfüllen. CSP kontrolliert, welche Ressourcen, etwa Skripte, Stylesheets oder Bilder, überhaupt geladen werden dürfen und von welchen Quellen, und schützt damit primär vor Cross-Site-Scripting und Dateninjektion. Permissions-Policy setzt eine Ebene höher an und kontrolliert nicht das Laden von Ressourcen, sondern den Zugriff auf Browser-APIs, nachdem der Code bereits geladen und ausgeführt wird.

Beide Header ergänzen sich deshalb, statt sich zu überschneiden: Eine strikte CSP verhindert, dass unbefugter Code überhaupt in die Seite gelangt, während eine strikte Permissions-Policy zusätzlich absichert, dass selbst legitim geladener, aber kompromittierter Code keine sensiblen Hardware-Schnittstellen missbrauchen kann. Ein Shop, der nur einen der beiden Header sauber konfiguriert, lässt eine Verteidigungsebene ungenutzt liegen.

7. Praktische Konfiguration für einen typischen Magento-Shop

Für einen typischen Hyvä-basierten Magento-Shop ohne eigene Video-Chat-Funktion, ohne native Zahlungs-Hardware-Integration und ohne AR-Features ist eine restriktive Grundkonfiguration sinnvoll. Kamera, Mikrofon, USB, MIDI und XR-Spatial-Tracking werden vollständig deaktiviert, Geolocation wird höchstens für den eigenen Ursprung erlaubt, falls ein Store-Locator diese Funktion tatsächlich benötigt, und Payment wird nur freigegeben, wenn eine In-Browser-Zahlungsmethode über das Payment-Request-API tatsächlich im Einsatz ist.

Fullscreen und Picture-in-Picture bleiben für den eigenen Ursprung sinnvoll, etwa für eingebettete Produktvideos, während autoplay ebenfalls auf self beschränkt bleibt, um zu verhindern, dass eingebettete Drittanbieter-Werbung automatisch mit Ton abspielt. Der Header lässt sich zentral über die nginx-Konfiguration des vHosts oder über eine Magento-Response-Header-Erweiterung setzen, sodass er konsistent auf jede Antwort angewendet wird, ohne einzelne Templates anpassen zu müssen.

8. Testing und Validierung: Fehlkonfigurationen erkennen

Nach dem Setzen des Headers lohnt sich eine systematische Prüfung über die Entwicklertools jedes gängigen Browsers, in denen sich unter dem Reiter für Anwendungssicherheit oder Netzwerk die tatsächlich ausgelieferten Response-Header inspizieren lassen. Zusätzlich zeigen viele Browser in der Konsole eine Warnung an, wenn ein Skript versucht, ein per Policy blockiertes Feature anzusprechen, was während der Testphase wertvolle Hinweise auf tatsächlich benötigte Features liefert.

Ein häufiger Fehler ist eine zu restriktive Konfiguration, die legitime Funktionen bricht, etwa wenn ein Zahlungsanbieter-iframe plötzlich sein eigenes Payment-Feature nicht mehr nutzen kann, weil die übergeordnete Policy es nicht für dessen Domain freigegeben hat. Ein strukturierter Testdurchlauf über alle kritischen Nutzerflüsse nach jeder Aenderung an der Policy verhindert, dass eine gut gemeinte Sicherheitsmaßnahme den eigentlichen Geschäftsbetrieb stört.

9. Grenzen des Headers und Browser-Kompatibilität

Permissions-Policy schützt zuverlässig gegen den Missbrauch der abgedeckten Browser-APIs, ersetzt aber keine anderen Sicherheitsmaßnahmen. Ein Angreifer, der bereits über eine andere Schwachstelle Zugriff auf Nutzerdaten erlangt hat, etwa über eine klassische Cross-Site-Scripting-Lücke ohne Bezug zu Hardware-APIs, wird durch diesen Header nicht aufgehalten. Die Maßnahme adressiert gezielt einen bestimmten Angriffsvektor und muss Teil einer umfassenderen Sicherheitsstrategie bleiben, nicht deren Ersatz.

Auch die Browser-Unterstützung ist nicht vollständig einheitlich: Während Chrome und darauf basierende Browser die meisten Direktiven umfassend unterstützen, hinken einzelne Features in Firefox oder Safari teils hinterher oder werden anders interpretiert. Ein Shop sollte deshalb regelmäßig aktuelle Kompatibilitätstabellen konsultieren und den Header so konfigurieren, dass er in nicht unterstützenden Browsern zumindest keinen Schaden anrichtet, da unbekannte Direktiven von der Spezifikation her einfach ignoriert werden.

10. Zusammenfassung

11. FAQ: Permissions-Policy-Header: Das Wichtigste auf einen Blick