Was ist der Permissions-Policy Header und warum ist er wichtig?
Der Permissions-Policy Header ist ein Response-Header, der einer Website erlaubt zu steuern, welche Browserfunktionen ihre eigenen Seiten und alle darin eingebetteten Inhalte nutzen dürfen. Funktionen wie Kamera, Mikrofon, Geolokalisierung und Zahlung können jeweils erlaubt, auf Ihre eigene Origin beschränkt oder ganz abgeschaltet werden. Ihn zu setzen bedeutet, dass der Browser die Nutzung verweigert, selbst wenn ein Skript oder ein eingebetteter Dritter versucht, eine dieser Funktionen zu erreichen, sofern Ihre Richtlinie es nicht erlaubt, was sowohl Ihre Datenschutzangriffsfläche als auch Ihre allgemeine Angriffsfläche verringert.
Warum gibt es den Permissions-Policy Header?
Moderne Browser stellen Webseiten viele leistungsstarke Fähigkeiten bereit: Standort, Kamera, Mikrofon, Bewegungssensoren und mehr. Jedes Skript, das auf Ihrer Seite läuft, einschließlich der Drittanbieter-Skripte, die Sie für Analytics, Chat oder Werbung eingebettet haben, kann den Browser im Prinzip auffordern, diese Fähigkeiten zu nutzen. Permissions-Policy existiert, damit Sie auf Ebene der gesamten Website festlegen können, welche dieser Funktionen erlaubt sind und für wen.
Der Sinn besteht darin, die Lücke zwischen dem, was ein Browser kann, und dem, was Ihre Website tatsächlich braucht, zu schließen. Die meisten Websites nutzen nie den Beschleunigungssensor oder die Payment-API, doch ohne Richtlinie bleiben diese Funktionen für jeden Code auf der Seite erreichbar. Laut der Dokumentation von MDN wird der Nutzer, wenn eine Richtlinie eine Funktion blockiert, nicht einmal um Erlaubnis gebeten, und der Versuch eines Skripts, sie zu nutzen, scheitert schlicht, was genau die Eindämmung ist, die Sie für Funktionen wünschen, die Sie nie nutzen wollten.
Was leistet der Permissions-Policy Header eigentlich?
Der Header funktioniert als Liste von Direktiven, eine pro Funktion, jede mit einer Allowlist, die angibt, welche Origins sie nutzen dürfen. Die Syntax ist der Funktionsname, ein Gleichheitszeichen und die erlaubten Origins in Klammern, wobei mehrere Direktiven durch Kommas getrennt werden, zum Beispiel geolocation=(), camera=(self). Eine leere Allowlist, geschrieben als (), schaltet die Funktion überall ab; self erlaubt sie nur auf Ihrer eigenen Origin; eine bestimmte Origin wie ("https://example.com") erlaubt diese Origin; und * erlaubt sie überall, auch in eingebetteten Frames.
Ein nützliches Detail ist, dass jede Funktion eine Standard-Allowlist hat, die gilt, wenn Sie nichts angeben, und je nach Funktion ist dieser Standard *, self oder keine. Der Wert, den Header explizit zu setzen, besteht also darin, dass Sie sich nicht länger auf die Standards je Funktion verlassen, sondern eine bewusste, einheitliche Entscheidung treffen: alles abschalten, was Sie nicht nutzen, und alles, was Sie nutzen, auf Ihre eigene Origin oder die bestimmten Partner beschränken, die es brauchen.
Wie verhält sich der Header mit eingebetteten iframes?
Das ist der Teil, über den die meisten stolpern, daher lohnt sich Genauigkeit. Eine Funktion ist innerhalb eines eingebetteten iframes nur verfügbar, wenn zwei Bedingungen zugleich erfüllt sind: Ihre Top-Level-Seite muss die Funktion für die Origin dieses Frames in ihrer Permissions-Policy erlauben, und das iframe selbst darf sie nicht deaktiviert haben. Anders gesagt setzt die übergeordnete Seite die äußere Grenze, und nichts Eingebettetes kann sich selbst eine Funktion gewähren, die die übergeordnete Seite vorenthalten hat.
Es gibt außerdem eine Steuerung je iframe, die neben dem Header wirkt, das allow-Attribut am iframe-Element, zum Beispiel eine eingebettete Karte, hinzugefügt mit einem Frame, dessen allow-Attribut geolocation erlaubt. Das Denkmodell, das Sie behalten sollten, ist, dass der Header die websiteweite Richtlinie ist und das allow-Attribut die Ausnahme je Einbettung darin: Der Frame kann nur erhalten, was der Header bereits erlaubt, und das Attribut grenzt es dann ein oder lenkt es auf diese bestimmte Einbettung. Genau deshalb meldet ein Drittanbieter-Widget manchmal, dass eine Funktion blockiert ist, obwohl der Code des Widgets korrekt ist, weil die enthaltende Seite diese Funktion für die Origin des Widgets nie erlaubt hat.
Was passiert, wenn Sie ihn nicht setzen?
Ohne den Header fällt jede Funktion auf ihre eigene Standard-Allowlist zurück, die für mehrere Funktionen freizügiger ist, als eine typische Website braucht. In der Praxis bedeutet das, dass Fähigkeiten, die Sie nie nutzen, erreichbar bleiben, und dass eingebettete Drittinhalte Funktionen anfordern können, die Sie nicht gewährt hätten, wenn man Sie gefragt hätte.
Dies ist meist keine dringende Lücke, weshalb sie unbehandelt bleibt, aber es ist eine echte. Sie wiegt am schwersten dort, wo Sie Code einbetten, den Sie nicht geschrieben haben: ein Analytics-Tag, ein Chat-Widget, ein Marketing-Pixel. Funktionen einzuschränken, die Sie nicht nutzen, verkleinert, was all dieser eingebettete Code versuchen kann, und es ist genau die Art fehlender Header, die Sicherheitsscanner und Audits inzwischen auf fast jeder Website kennzeichnen, die ihn nicht gesetzt hat.
Wie implementieren Sie den Permissions-Policy Header?
Sie setzen Permissions-Policy als einen einzigen HTTP-Response-Header. Eine sinnvolle Ausgangsrichtlinie besteht darin, die Funktionen abzuschalten, von denen Sie wissen, dass Sie sie nicht nutzen, und den Rest auf Ihre eigene Origin zu beschränken, zum Beispiel Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=(), und dann einzelne Direktiven nur dort zu lockern, wo ein echter Bedarf besteht. Er kann am Webserver, in der Anwendungsebene oder am Rand in einem CDN oder einer Sicherheitsschicht vor der Website angewendet werden.
Es hilft, dies an einer echten Website statt im Abstrakten zu betrachten. Nehmen Sie eine Klinik-Website, die eine eingebettete Karte zeigt, damit Patienten die Praxis finden, und ein Online-Buchungstool betreibt, das einen Bezahlschritt öffnet, aber sonst keine Browserfunktionen nutzt. Eine auf diese Website zugeschnittene Richtlinie würde alles abschalten, was sie nie berührt, und nur erlauben, was diese beiden Funktionen brauchen: geolocation beschränkt auf die Origin des Kartenanbieters, payment beschränkt auf den Buchungs- oder Zahlungsanbieter, und Kamera, Mikrofon und die verschiedenen Sensorfunktionen alle mit einer leeren Allowlist abgeschaltet. Das Ergebnis ist eine Seite, auf der Karte und Bezahlvorgang genau wie zuvor funktionieren, während jede andere Fähigkeit für jedes Skript schlicht nicht verfügbar ist, ob dieses Skript Ihres ist oder zu einem eingebetteten Dritten gehört. Das Prinzip lässt sich verallgemeinern: Listen Sie auf, was die Website wirklich nutzt, erlauben Sie diese den bestimmten Origins, die sie bereitstellen, und schließen Sie den Rest.
Testen Sie, bevor Sie ihn festzurren. Der Header hat einen Report-only-Begleiter, Permissions-Policy-Report-Only, der die Reporting-API des Browsers nutzt, um Ihnen mitzuteilen, was eine Richtlinie blockieren würde, ohne sie tatsächlich durchzusetzen. Diesen zuerst zu betreiben ist der sichere Weg, um herauszufinden, ob eine echte Funktion, eine Karte, die geolocation braucht, ein Buchungstool, das einen Zahlungsablauf öffnet, ein eingebettetes Video, von Ihrer Richtlinie erfasst würde, sodass Sie sie bewusst erlauben, statt sie überraschend zu brechen.
Was ändert sich auf Ihrer Website, sobald er aktiv ist?
Für die meisten Websites nichts Sichtbares. Gewöhnliche Seiten, die keine eingeschränkten Funktionen nutzen, verhalten sich genau wie zuvor, und Besucher bemerken nichts, weil die Richtlinie nur eingreift, wenn Code versucht, eine Funktion zu erreichen, die Sie nicht erlaubt haben.
Zu prüfen ist jede Funktion, auf die Ihre eigene Website wirklich angewiesen ist, und alles, was Ihre eingebetteten Dritten brauchen. Ein Filialfinder mit Geolokalisierung, eine Videoanruf-Funktion mit Kamera und Mikrofon oder ein Checkout mit der Payment-API müssen alle ihre Direktiven so gesetzt haben, dass die richtigen Origins erlaubt sind, was genau der Grund ist, warum Tests im Report-only-Modus vor der Durchsetzung wichtig sind. Machen Sie das einmal richtig, und der Header hält danach leise die Linie, erlaubt, was Sie beabsichtigt haben, und verweigert alles andere.
Was sollten Sie als Nächstes tun?
Prüfen Sie zunächst, ob Ihre Website überhaupt einen Permissions-Policy Header sendet, denn ohne ihn fällt jede Funktion schlicht auf ihren Standard zurück. Fehlt er, ist der risikoarme Weg, ihn im Report-only-Modus hinzuzufügen, die Funktionen aufzulisten, die Sie tatsächlich nutzen, zu bestätigen, dass nichts, worauf Sie angewiesen sind, blockiert wird, und dann eine Richtlinie durchzusetzen, die alles andere abschaltet.
Wenn Sie dies über Ihre gesamte Website hinweg korrekt prüfen und konfigurieren lassen möchten statt Stück für Stück, kann EuroraCloud Ihre aktuellen Security Header prüfen und Ihnen zeigen, was unsere Plattform löst. Sehen Sie, was EuroraCloud löst
Fazit: Was sollten Sie zum Permissions-Policy Header mitnehmen?
Permissions-Policy ist ein leiser, praktischer Header: Er lässt Sie die Browserfunktionen abschalten, die Ihre Website nie nutzt, und jene, die sie nutzt, auf genau die Origins beschränken, die sie brauchen, sodass weder Ihre eigenen Skripte noch eingebettete Dritte Fähigkeiten erreichen können, die Sie nie offenlegen wollten. Der sichere Weg der Einführung ist, im Report-only-Modus zu testen, zu bestätigen, dass Ihre echten Funktionen weiterhin arbeiten, und dann eine Richtlinie durchzusetzen, die den Rest abschaltet. Der nützlichste Schritt ist zu prüfen, ob Ihre Website den Header heute sendet, denn solange sie das nicht tut, bleibt jede Funktion auf ihrem Standard.