Permissions-Policy ist ein HTTP-Response-Header, der Website-Betreibern detaillierte Kontrolle darueber gibt, welche Browser-Funktionen und APIs auf ihren Seiten genutzt werden duerfen, und vor allem, welche Funktionen eingebettete Drittanbieter-Inhalte verwenden koennen. Wenn du dich jemals gefragt hast, wie eine Werbeanzeige in einem iframe stillschweigend Zugriff auf die Kamera oder das Mikrofon deiner Besucher anfordern koennte, dann ist Permissions-Policy genau der Mechanismus, der das verhindern soll.
Der Header wurde urspruenglich unter dem Namen Feature-Policy eingefuehrt. Browser begannen um 2018 herum mit der Unterstuetzung, aber die Spezifikation durchlief erhebliche Aenderungen und der Header wurde schliesslich in Permissions-Policy mit einer neuen Syntax umbenannt. Heute erkennen die meisten modernen Browser den Permissions-Policy-Header, obwohl einige aeltere Browser moeglicherweise noch nur das Legacy-Format Feature-Policy verstehen. Fuer maximale Kompatibilitaet kannst du beide Header senden, aber Permissions-Policy ist der zukunftssichere Standard.
Welche Browser-Funktionen gesteuert werden koennen
Die Liste der Funktionen, die du ueber Permissions-Policy einschraenken kannst, ist ueberraschend lang und waechst stetig mit neuen Browser-Faehigkeiten. Hier sind die relevantesten fuer WordPress-Betreiber:
camera: steuert den Zugriff auf die Geraetekamera. 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 ausloesen koennen. WooCommerce und andere E-Commerce-Plugins koennen dies fuer einen optimierten Checkout nutzen.fullscreen: steuert, ob eingebettete Inhalte den Vollbildmodus anfordern koennen. Video-Player, Galerie-Lightboxen und Praesentations-Plugins benoetigen dies typischerweise.autoplay: steuert, ob Medienelemente automatisch abspielen koennen. Dies betrifft Hintergrund-Video-Header, automatisch abspielende Slider und eingebettete YouTube- oder Vimeo-Player.display-capture: steuert Bildschirmfreigabe-Faehigkeiten. Hauptsaechlich relevant fuer Konferenz- oder Support-Tools auf deiner Seite.usb: steuert die WebUSB-API. Selten auf typischen WordPress-Seiten benoetigt, aber manchmal von spezialisierten Hardware-Integrations-Plugins verwendet.bluetooth: steuert den Web-Bluetooth-Zugriff. Aehnlich wie USB eher eine Nische, aber standardmaessig 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 vollstaendig deaktiviert ist, auch fuer die eigene Seite:
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()Wenn du eine Funktion fuer deine eigene Herkunft erlauben, aber fuer alle eingebetteten Drittanbieter-Inhalte blockieren moechtest, verwendest du das Schluesselwort self:
Permissions-Policy: camera=(self), geolocation=(self "https://maps.example.com")In diesem Beispiel koennen deine eigenen Seiten auf die Kamera zugreifen, und Geolokalisierung ist sowohl fuer deine Herkunft als auch fuer einen vertrauenswuerdigen Kartenanbieter verfuegbar. Jede andere eingebettete Herkunft wird an der Nutzung dieser Funktionen gehindert.
Wie Drittanbieter-Iframes Browser-Berechtigungen missbrauchen
Das primaere 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, laeuft diese Einbettung in einem iframe mit eigenem Ausfuehrungskontext. 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 boesartiges Werbebanner koennte navigator.mediaDevices.getUserMedia() aufrufen, um Kamera- oder Mikrofonzugriff anzufordern. Der Browser wuerde dem Besucher eine Berechtigungsabfrage anzeigen, aber die Abfrage sagt nur, dass die Website Zugriff anfordert. Die meisten Nutzer wuerden 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 gefaehrlicher, da er irrefuehrende Zahlungsdialoge ausloesen koennte. Durch eine strikte Permissions-Policy unterbindest du all diese Angriffsvektoren auf Browser-Ebene, unabhaengig davon, welches JavaScript die Einbettung ausfuehren versucht.
Die Beziehung zum aelteren 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 urspruengliche 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 unterstuetzt.
Das W3C ueberarbeitete schliesslich 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 spaeter. Heute gilt Feature-Policy als veraltet. Die meisten Sicherheitsscanner und Tools (einschliesslich InspectWP) pruefen spezifisch auf den Permissions-Policy-Header. Wenn dein Server noch den alten Feature-Policy-Header sendet, funktioniert er generell noch in Browsern, die ihn unterstuetzen, aber du solltest die Migration zum neuen Format planen.
WordPress-spezifische Aspekte
WordPress-Seiten sind besonders von Permissions-Policy betroffen, weil das Plugin-Oekosystem 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 gaengige Szenarien, in denen Permissions-Policy relevant wird:
- Kontaktformular-Plugins mit Datei-Upload-Feldern, die auf Mobilgeraeten Kameraaufnahmen anbieten.
- WooCommerce-Checkout-Seiten, die ueber iframes mit Zahlungsanbietern integriert sind.
- Google-Maps-Einbettungen, die Geolokalisierung anfordern, um die Position des Nutzers anzuzeigen.
- Videokonferenz-Plugins (fuer Online-Kurse oder Support), die Kamera- und Mikrofonzugriff benoetigen.
- 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 tatsaechlich benoetigt. So wird selbst dann, wenn ein Plugin einen unerwarteten Drittanbieter-iframe laedt, der Browser den Zugriff auf sensible Funktionen blockieren.
Wie man den Permissions-Policy-Header in WordPress setzt
Du kannst den Header ueber deine Webserver-Konfiguration oder ueber ein WordPress-Plugin hinzufuegen. Fuer Apache wuerdest du eine Zeile in deine .htaccess-Datei einfuegen:
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), bluetooth=()"Fuer Nginx gehoert das Aequivalent 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 muessen.
Was InspectWP prueft
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) moeglicherweise auf sensible Browser-Funktionen wie Kamera, Mikrofon oder Geolokalisierung ohne jegliche Einschraenkung zugreifen koennen. Der Report zeigt auch den rohen Header-Wert an, damit du ueberpruefen kannst, welche Funktionen aktuell eingeschraenkt sind.