Permissions-Policy is een HTTP-response-header die website-eigenaren nauwkeurige controle geeft over welke browserfuncties en API's op hun pagina's gebruikt mogen worden, en cruciaal: tot welke functies ingesloten content van derden toegang krijgt. Heeft u zich ooit afgevraagd hoe een advertentie binnen een iframe stilletjes toegang tot de camera of microfoon van uw bezoeker kan vragen, dan is Permissions-Policy het mechanisme dat juist dat moet voorkomen.
De header werd oorspronkelijk geïntroduceerd onder de naam Feature-Policy. Browsers begonnen rond 2018 met de ondersteuning ervan, maar de specificatie onderging belangrijke wijzigingen, en de header is uiteindelijk hernoemd tot Permissions-Policy met een nieuwe syntax. Tegenwoordig herkennen de meeste moderne browsers de Permissions-Policy-header, hoewel sommige oudere browsers mogelijk alleen het verouderde Feature-Policy-formaat begrijpen. Voor maximale compatibiliteit kunt u beide headers versturen, maar Permissions-Policy is degene waarop u zich vooruit moet richten.
Welke browserfuncties beheerst kunnen worden
De lijst met functies die u via Permissions-Policy kunt beperken is verrassend lang en blijft groeien naarmate browsers nieuwe mogelijkheden toevoegen. Hier zijn de meest relevante voor WordPress-site-eigenaren:
camera: bepaalt toegang tot de camera van het apparaat. Relevant als u een lidmaatschapssite met video-uploads draait of een plugin die webcam-gebaseerde profielfoto's biedt.microphone: bepaalt toegang tot audio-opname. Voice-search-plugins, podcastopnametools en livechat-widgets vragen hier soms om.geolocation: bepaalt toegang tot de GPS- of netwerkgebaseerde locatie van de bezoeker. Vestigingszoekers, kaartwidgets en locatiegebonden contentlevering kunnen hierom vragen.payment: bepaalt de Payment Request API, waarmee websites native browser-betaaldialogen kunnen activeren. WooCommerce en andere e-commerce-plugins kunnen dit gebruiken voor een gestroomlijnd afrekenproces.fullscreen: bepaalt of ingesloten content de volledige-schermmodus mag aanvragen. Videospelers, galerij-lightboxes en presentatie-plugins hebben dit doorgaans nodig.autoplay: bepaalt of media-elementen automatisch mogen afspelen. Dit beïnvloedt achtergrondvideo-headers, automatisch afspelende sliders en ingesloten YouTube- of Vimeo-spelers.display-capture: bepaalt schermdelingsmogelijkheden. Vooral relevant voor conferentie- of supporttools die op uw site zijn ingesloten.usb: bepaalt de WebUSB API. Zelden nodig op typische WordPress-sites, maar soms gebruikt door gespecialiseerde hardware-integratieplugins.bluetooth: bepaalt Web Bluetooth-toegang. Vergelijkbaar met USB; nichefunctie, maar standaard de moeite waard om te beperken.interest-cohort: werd gebruikt om af te zien van Google's FLoC-trackingvoorstel. Hoewel FLoC vervangen is door de Topics API, sturen veel sites deze directive nog steeds.
Hoe de syntax werkt
De Permissions-Policy-header gebruikt een eenvoudige syntax. Elke functie wordt gevolgd door een toelatingslijst tussen haakjes. Lege haakjes betekenen dat de functie volledig is uitgeschakeld voor iedereen, ook voor uw eigen pagina:
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()Wilt u een functie toestaan voor uw eigen origin, maar blokkeren voor alle ingesloten content van derden, dan gebruikt u het sleutelwoord self:
Permissions-Policy: camera=(self), geolocation=(self "https://maps.example.com")In dit voorbeeld kunnen uw eigen pagina's de camera benaderen, en is geolocation beschikbaar voor zowel uw origin als een vertrouwde kaartenprovider. Elke andere ingesloten origin wordt geblokkeerd voor het gebruik van die functies. U kunt ook * gebruiken om alle origins toe te staan, maar dat ondergraaft het hele doel van de header.
Hoe iframes van derden browser-permissies misbruiken
Het primaire dreigingsmodel achter Permissions-Policy is het ingesloten iframe. Wanneer u een advertentienetwerk, social-media-widget, chattool of een andere embed van derden op uw WordPress-site opneemt, draait die embed in een iframe met een eigen executiecontext. Zonder Permissions-Policy-header behandelt de browser dat iframe wat betreft toegang tot functies bijna als een first-party-pagina.
Dit betekent dat een slecht gecodeerde of regelrecht kwaadaardige advertentie navigator.mediaDevices.getUserMedia() kan aanroepen om toegang tot camera of microfoon te vragen. De browser toont de bezoeker een toestemmingsverzoek, maar dat verzoek vermeldt slechts dat de site om toegang vraagt. De meeste gebruikers realiseren zich niet dat het verzoek afkomstig is van een ingesloten advertentie, in plaats van van de website die ze bezoeken. Klikken ze op "Toestaan", dan beschikt de advertentie over een live video- of audiofeed.
Misbruik van geolocation is nog subtieler. Sommige advertentienetwerken zijn betrapt op het opvragen van locatiegegevens om gedetailleerdere gebruikersprofielen te bouwen. Misbruik van de Payment API komt minder vaak voor, maar is potentieel gevaarlijker, omdat het misleidende betaaldialogen kan triggeren. Met een strikte Permissions-Policy snijdt u al deze aanvalsvectoren op browserniveau af, ongeacht welk JavaScript de embed probeert te draaien.
De relatie tot de oudere Feature-Policy-header
Bent u verwijzingen naar Feature-Policy tegengekomen en vraagt u zich af of het hetzelfde is: ja, in essentie wel. Feature-Policy was de oorspronkelijke naam en gebruikte een iets andere syntax. In plaats van camera=(self) zag het oude formaat eruit als camera 'self'. De Feature-Policy-header werd vanaf ongeveer 2018 ondersteund door Chrome, Firefox en andere browsers.
Het W3C heeft de specificatie uiteindelijk herontworpen met een schonere syntax en hernoemde hem tot Permissions-Policy. Chrome stapte over op de nieuwe header in versie 88 (januari 2021). Firefox volgde later. Op dit moment wordt Feature-Policy als verouderd beschouwd. De meeste beveiligingsscanners en tools (waaronder InspectWP) controleren specifiek op de Permissions-Policy-header. Verstuurt uw server nog de oude Feature-Policy-header, dan zal die meestal nog werken in browsers die hem ondersteunen, maar plan een migratie naar het nieuwe formaat.
WordPress-specifieke overwegingen
WordPress-sites worden bijzonder geraakt door Permissions-Policy vanwege de werking van het plugin-ecosysteem. Een typische WordPress-site heeft 15 tot 30 actieve plugins, en veel daarvan injecteren iframes of laden scripts van derden. Hier zijn veelvoorkomende scenario's waarin Permissions-Policy ertoe doet:
- Contactformulier-plugins met file-upload-velden die op mobiele apparaten cameraregistratie aanbieden.
- WooCommerce-checkout-pagina's die via iframes integreren met betaalproviders.
- Google Maps-embeds die geolocation aanvragen om de positie van de gebruiker te tonen.
- Videoconferentie-plugins (voor online cursussen of support) die toegang tot camera en microfoon nodig hebben.
- Advertentiebeheer-plugins die op uw pagina's iframes van advertentienetwerken insluiten.
De juiste aanpak is om te starten met een restrictief beleid dat alles uitschakelt en vervolgens selectief de functies in te schakelen die uw site daadwerkelijk nodig heeft. Zo blokkeert de browser, ook als een plugin een onverwacht iframe van een derde laadt, de toegang tot gevoelige functies.
Hoe u de Permissions-Policy-header instelt in WordPress
U kunt de header toevoegen via uw webserverconfiguratie of via een WordPress-plugin. Voor Apache voegt u een regel toe aan uw .htaccess:
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), bluetooth=()"Voor Nginx komt het equivalent in uw server-blok:
add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), bluetooth=()" always;Beveiligingsplugins zoals HTTP Headers, Really Simple Security of Perfmatters bieden ook UI-gebaseerde besturing voor het instellen van de Permissions-Policy-header zonder dat u serverconfiguratiebestanden hoeft aan te raken.
Wat InspectWP controleert
InspectWP analyseert of uw WordPress-site een Permissions-Policy-header in zijn HTTP-responses verstuurt. Ontbreekt de header, dan signaleert het rapport dit als een beveiligingsprobleem, omdat ingesloten content van derden (advertenties, widgets, iframes) zonder enige beperking toegang kan krijgen tot gevoelige browserfuncties als camera, microfoon of geolocation. Het rapport toont ook de ruwe headerwaarde, zodat u kunt verifiëren welke functies momenteel beperkt zijn.