Permissions-Policy ist ein HTTP-Response-Header, der Website-Betreibern detaillierte Kontrolle darüber gibt, welche Browser-Funktionen und APIs auf ihren Seiten genutzt werden dürfen, und vor allem, welche Funktionen eingebettete Drittanbieter-Inhalte verwenden können. Wenn du dich jemals gefragt hast, wie eine Werbeanzeige in einem iframe stillschweigend Zugriff auf die Kamera oder das Mikrofon deiner Besucher anfordern könnte, dann ist Permissions-Policy genau der Mechanismus, der das verhindern soll.
Der Header wurde ursprünglich unter dem Namen Feature-Policy eingeführt. Browser begannen um 2018 herum mit der Unterstützung, aber die Spezifikation durchlief erhebliche Änderungen, und der Header wurde schließlich in Permissions-Policy mit einer neuen Syntax umbenannt. Heute erkennen die meisten modernen Browser den Permissions-Policy-Header, obwohl einige ältere Browser möglicherweise noch nur das Legacy-Format Feature-Policy verstehen. Für maximale Kompatibilität kannst du beide Header senden, aber Permissions-Policy ist der zukunftssichere Standard.
Welche Browser-Funktionen gesteuert werden können
Die Liste der Funktionen, die du über Permissions-Policy einschränken kannst, ist überraschend lang und wächst stetig mit neuen Browser-Fähigkeiten. Hier sind die relevantesten für WordPress-Betreiber:
camera: Steuert den Zugriff auf die Gerätekamera. Relevant, wenn du eine Mitgliederseite mit Video-Uploads betreibst oder ein Plugin verwendest, das Webcam-basierte Profilfotos anbietet.microphone: Steuert den Zugriff auf Audioaufnahmen. Sprachsuche-Plugins, Podcast-Aufnahme-Tools und Live-Chat-Widgets fordern dies manchmal an.geolocation: Steuert den Zugriff auf GPS- oder netzwerkbasierte Standortdaten des Besuchers. Filialfinder-Plugins, Karten-Widgets und standortbasierte Inhaltsauslieferung nutzen dies.payment: Steuert die Payment Request API, mit der Websites native Browser-Zahlungsdialoge auslösen können. WooCommerce und andere E-Commerce-Plugins können dies für einen optimierten Checkout nutzen.fullscreen: Steuert, ob eingebettete Inhalte den Vollbildmodus anfordern können. Video-Player, Galerie-Lightboxen und Präsentations-Plugins benötigen dies typischerweise.autoplay: Steuert, ob Medienelemente automatisch abspielen können. Dies betrifft Hintergrund-Video-Header, automatisch abspielende Slider und eingebettete YouTube- oder Vimeo-Player.display-capture: Steuert Bildschirmfreigabe-Fähigkeiten. Hauptsächlich relevant für Konferenz- oder Support-Tools auf deiner Seite.usb: Steuert die WebUSB-API. Selten auf typischen WordPress-Seiten benötigt, aber manchmal von spezialisierten Hardware-Integrations-Plugins verwendet.bluetooth: Steuert den Web-Bluetooth-Zugriff. Ähnlich wie USB eher eine Nische, aber standardmäßig empfehlenswert zu blockieren.interest-cohort: Wurde verwendet, um Googles FLoC-Tracking-Vorschlag abzulehnen. Obwohl FLoC durch die Topics API ersetzt wurde, senden viele Seiten diese Direktive noch immer.
Wie die Syntax funktioniert
Der Permissions-Policy-Header verwendet eine unkomplizierte Syntax. Jede Funktion wird von einer Erlaubnisliste in Klammern gefolgt. Leere Klammern bedeuten, dass die Funktion vollständig deaktiviert ist, auch für die eigene Seite:
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()Wenn du eine Funktion für deine eigene Herkunft erlauben, aber für alle eingebetteten Drittanbieter-Inhalte blockieren möchtest, verwendest du das Schlüsselwort self:
Permissions-Policy: camera=(self), geolocation=(self "https://maps.example.com")In diesem Beispiel können deine eigenen Seiten auf die Kamera zugreifen, und Geolokalisierung ist sowohl für deine Herkunft als auch für einen vertrauenswürdigen Kartenanbieter verfügbar. Jede andere eingebettete Herkunft wird an der Nutzung dieser Funktionen gehindert.
Wie Drittanbieter-Iframes Browser-Berechtigungen missbrauchen
Das primäre Bedrohungsmodell hinter Permissions-Policy ist der eingebettete iframe. Wenn du ein Werbenetzwerk, ein Social-Media-Widget, ein Chat-Tool oder eine andere Drittanbieter-Einbettung auf deiner WordPress-Seite einbindest, läuft diese Einbettung in einem iframe mit eigenem Ausführungskontext. Ohne einen Permissions-Policy-Header behandelt der Browser diesen iframe fast wie eine First-Party-Seite, was den Zugriff auf Funktionen betrifft.
Das bedeutet, ein schlecht programmiertes oder bösartiges Werbebanner könnte navigator.mediaDevices.getUserMedia() aufrufen, um Kamera- oder Mikrofonzugriff anzufordern. Der Browser würde dem Besucher eine Berechtigungsabfrage anzeigen, aber die Abfrage sagt nur, dass die Website Zugriff anfordert. Die meisten Nutzer würden nicht erkennen, dass die Anfrage von einer eingebetteten Werbung stammt und nicht von der eigentlichen Website. Wenn sie auf „Erlauben" klicken, hat die Werbung einen Live-Video- oder Audio-Feed.
Geolokalisierungs-Missbrauch ist noch subtiler. Einige Werbenetzwerke wurden dabei erwischt, Standortdaten anzufordern, um detailliertere Nutzerprofile aufzubauen. Payment-API-Missbrauch ist seltener, aber potenziell gefährlicher, da er irreführende Zahlungsdialoge auslösen könnte. Durch eine strikte Permissions-Policy unterbindest du all diese Angriffsvektoren auf Browser-Ebene, unabhängig davon, welches JavaScript die Einbettung auszuführen versucht.
Die Beziehung zum älteren Feature-Policy-Header
Falls du Verweise auf Feature-Policy gesehen hast und dich gefragt hast, ob es sich um dasselbe handelt: Im Wesentlichen ja. Feature-Policy war der ursprüngliche Name und verwendete eine leicht andere Syntax. Statt camera=(self) sah das alte Format wie camera 'self' aus. Der Feature-Policy-Header wurde ab etwa 2018 von Chrome, Firefox und anderen Browsern unterstützt.
Das W3C überarbeitete schließlich die Spezifikation mit einer saubereren Syntax und benannte sie in Permissions-Policy um. Chrome wechselte in Version 88 (Januar 2021) zum neuen Header. Firefox folgte später. Heute gilt Feature-Policy als veraltet. Die meisten Sicherheitsscanner und Tools (einschließlich InspectWP) prüfen spezifisch auf den Permissions-Policy-Header. Wenn dein Server noch den alten Feature-Policy-Header sendet, funktioniert er generell noch in Browsern, die ihn unterstützen, aber du solltest die Migration zum neuen Format planen.
WordPress-spezifische Aspekte
WordPress-Seiten sind besonders von Permissions-Policy betroffen, weil das Plugin-Ökosystem viele Drittanbieter-Integrationen mit sich bringt. Eine typische WordPress-Seite hat 15 bis 30 aktive Plugins, und viele davon laden iframes oder Drittanbieter-Skripte. Hier sind gängige Szenarien, in denen Permissions-Policy relevant wird:
- Kontaktformular-Plugins mit Datei-Upload-Feldern, die auf Mobilgeräten Kameraaufnahmen anbieten.
- WooCommerce-Checkout-Seiten, die über iframes mit Zahlungsanbietern integriert sind.
- Google-Maps-Einbettungen, die Geolokalisierung anfordern, um die Position des Nutzers anzuzeigen.
- Videokonferenz-Plugins (für Online-Kurse oder Support), die Kamera- und Mikrofonzugriff benötigen.
- Werbeverwaltungs-Plugins, die Werbenetzwerk-Iframes auf deinen Seiten einbetten.
Der richtige Ansatz ist, mit einer restriktiven Richtlinie zu beginnen, die alles deaktiviert, und dann selektiv Funktionen freizugeben, die deine Seite tatsächlich benötigt. So wird selbst dann, wenn ein Plugin einen unerwarteten Drittanbieter-iframe lädt, der Browser den Zugriff auf sensible Funktionen blockieren.
Wie man den Permissions-Policy-Header in WordPress setzt
Du kannst den Header über deine Webserver-Konfiguration oder über ein WordPress-Plugin hinzufügen. Für Apache würdest du eine Zeile in deine .htaccess-Datei einfügen:
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), bluetooth=()"Für Nginx gehört das Äquivalent in deinen Server-Block:
add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), bluetooth=()" always;Sicherheits-Plugins wie HTTP Headers, Really Simple Security oder Perfmatters bieten auch UI-basierte Steuerungen zum Setzen des Permissions-Policy-Headers, ohne Serverkonfigurationsdateien bearbeiten zu müssen.
Was InspectWP prüft
InspectWP analysiert, ob deine WordPress-Seite einen Permissions-Policy-Header in ihren HTTP-Antworten sendet. Wenn der Header fehlt, markiert der Report dies als Sicherheitsbedenken, weil eingebettete Drittanbieter-Inhalte (Werbung, Widgets, Iframes) möglicherweise auf sensible Browser-Funktionen wie Kamera, Mikrofon oder Geolokalisierung ohne jegliche Einschränkung zugreifen können. Der Report zeigt auch den rohen Header-Wert an, damit du überprüfen kannst, welche Funktionen aktuell eingeschränkt sind.