Permissions-Policy est un en-tête de réponse HTTP qui donne aux propriétaires de sites web un contrôle précis sur les fonctionnalités et API du navigateur pouvant être utilisées sur leurs pages, et surtout sur celles auxquelles le contenu tiers intégré est autorisé à accéder. Si vous vous êtes déjà demandé comment une publicité dans une iframe pourrait demander silencieusement l'accès à la caméra ou au microphone de votre visiteur, Permissions-Policy est le mécanisme conçu pour empêcher exactement cela.
L'en-tête a été initialement introduit sous le nom de Feature-Policy. Les navigateurs ont commencé à le prendre en charge vers 2018, mais la spécification a subi des changements importants, et l'en-tête a finalement été renommé Permissions-Policy avec une nouvelle syntaxe. Aujourd'hui, la plupart des navigateurs modernes reconnaissent l'en-tête Permissions-Policy, bien que certains navigateurs plus anciens ne comprennent encore que l'ancien format Feature-Policy. Si vous voulez une compatibilité maximale, vous pouvez envoyer les deux en-têtes, mais Permissions-Policy est celui à privilégier à l'avenir.
Quelles fonctionnalités du navigateur peuvent être contrôlées
La liste des fonctionnalités que vous pouvez restreindre via Permissions-Policy est étonnamment longue, et elle continue de s'étendre à mesure que les navigateurs ajoutent de nouvelles capacités. Voici les plus pertinentes pour les propriétaires de sites WordPress :
camera: contrôle l'accès à la caméra de l'appareil. Pertinent si vous gérez un site d'adhésion avec téléversement de vidéos ou une extension proposant des photos de profil basées sur la webcam.microphone: contrôle l'accès à l'enregistrement audio. Les extensions de recherche vocale, outils d'enregistrement de podcasts et widgets de chat en direct le demandent parfois.geolocation: contrôle l'accès à la position GPS ou basée sur le réseau du visiteur. Les extensions de localisation de magasins, widgets de cartes et la diffusion de contenu basée sur la position peuvent en avoir besoin.payment: contrôle l'API Payment Request, qui permet aux sites web de déclencher des dialogues de paiement natifs du navigateur. WooCommerce et d'autres extensions e-commerce peuvent l'utiliser pour un paiement simplifié.fullscreen: contrôle si le contenu intégré peut demander le mode plein écran. Les lecteurs vidéo, les lightbox de galeries et les extensions de présentation en ont généralement besoin.autoplay: contrôle si les éléments multimédias peuvent se lire automatiquement. Cela affecte les vidéos d'arrière-plan, les sliders à lecture automatique et les lecteurs YouTube ou Vimeo intégrés.display-capture: contrôle les capacités de partage d'écran. Cela concerne principalement les outils de conférence ou de support intégrés à votre site.usb: contrôle l'API WebUSB. Rarement nécessaire sur les sites WordPress typiques, mais parfois utilisée par des extensions d'intégration matérielle spécialisées.bluetooth: contrôle l'accès à Web Bluetooth. Comme USB, c'est un cas de niche mais qui mérite d'être restreint par défaut.interest-cohort: utilisé pour se désinscrire de la proposition de suivi FLoC de Google. Bien que FLoC ait été remplacé par l'API Topics, de nombreux sites envoient encore cette directive.
Comment fonctionne la syntaxe
L'en-tête Permissions-Policy utilise une syntaxe simple. Chaque fonctionnalité est suivie d'une liste d'autorisation entre parenthèses. Des parenthèses vides signifient que la fonctionnalité est complètement désactivée pour tout le monde, y compris votre propre page :
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()Si vous voulez autoriser une fonctionnalité pour votre propre origine mais la bloquer pour tout contenu tiers intégré, utilisez le mot-clé self :
Permissions-Policy: camera=(self), geolocation=(self "https://maps.example.com")Dans cet exemple, vos propres pages peuvent accéder à la caméra, et la géolocalisation est disponible pour votre origine et un fournisseur de cartes de confiance. Toute autre origine intégrée est bloquée. Vous pouvez également utiliser * pour autoriser toutes les origines, mais cela va à l'encontre de l'objectif de définir l'en-tête.
Comment les iframes tierces abusent des permissions du navigateur
Le principal modèle de menace derrière Permissions-Policy est l'iframe intégrée. Lorsque vous incluez un réseau publicitaire, un widget de réseau social, un outil de chat ou tout autre contenu intégré tiers sur votre site WordPress, ce contenu s'exécute dans une iframe avec son propre contexte d'exécution. Sans en-tête Permissions-Policy, le navigateur traite cette iframe presque comme une page de première partie en matière d'accès aux fonctionnalités.
Cela signifie qu'une publicité mal codée ou carrément malveillante pourrait appeler navigator.mediaDevices.getUserMedia() pour demander l'accès à la caméra ou au microphone. Le navigateur afficherait une demande de permission au visiteur, mais celle-ci indique simplement que le site demande l'accès. La plupart des utilisateurs ne réaliseraient pas que la demande provient d'une publicité intégrée et non du site web réel qu'ils visitent. S'ils cliquent sur "Autoriser", la publicité dispose désormais d'un flux vidéo ou audio en direct.
L'abus de la géolocalisation est encore plus subtil. Certains réseaux publicitaires ont été surpris à demander des données de localisation pour construire des profils utilisateur plus détaillés. L'abus de l'API de paiement est moins courant mais potentiellement plus dangereux, car il pourrait déclencher des dialogues de paiement trompeurs. En définissant une Permissions-Policy stricte, vous coupez tous ces vecteurs au niveau du navigateur, quel que soit le JavaScript que l'élément intégré tente d'exécuter.
Relation avec l'ancien en-tête Feature-Policy
Si vous avez vu des références à Feature-Policy et vous vous demandez s'il s'agit de la même chose : oui, essentiellement. Feature-Policy était le nom original et utilisait une syntaxe légèrement différente. Au lieu de camera=(self), l'ancien format ressemblait à camera 'self'. L'en-tête Feature-Policy était pris en charge par Chrome, Firefox et d'autres navigateurs à partir de 2018 environ.
Le W3C a finalement repensé la spécification avec une syntaxe plus propre et l'a renommée Permissions-Policy. Chrome est passé au nouvel en-tête dans la version 88 (janvier 2021). Firefox a suivi plus tard. Aujourd'hui, Feature-Policy est considéré comme obsolète. La plupart des scanners et outils de sécurité (y compris InspectWP) vérifient spécifiquement l'en-tête Permissions-Policy. Si votre serveur envoie encore l'ancien en-tête Feature-Policy, il fonctionnera généralement encore dans les navigateurs qui le prennent en charge, mais vous devriez prévoir de migrer vers le nouveau format.
Considérations spécifiques à WordPress
Les sites WordPress sont particulièrement concernés par Permissions-Policy en raison du fonctionnement de l'écosystème des extensions. Un site WordPress typique peut avoir 15 à 30 extensions actives, et beaucoup d'entre elles injectent des iframes ou chargent des scripts tiers. Voici des scénarios courants où Permissions-Policy est important :
- Extensions de formulaires de contact avec champs de téléversement de fichiers proposant la capture par caméra sur les appareils mobiles.
- Pages de paiement WooCommerce qui s'intègrent à des passerelles de paiement via des iframes.
- Intégrations Google Maps qui demandent la géolocalisation pour afficher la position de l'utilisateur.
- Extensions de visioconférence (pour les cours en ligne ou le support) nécessitant l'accès à la caméra et au microphone.
- Extensions de gestion publicitaire qui intègrent des iframes de réseaux publicitaires sur vos pages.
La bonne approche consiste à commencer par une politique restrictive qui désactive tout, puis à activer sélectivement les fonctionnalités dont votre site a réellement besoin. Ainsi, même si une extension charge une iframe tierce inattendue, le navigateur l'empêchera d'accéder aux fonctionnalités sensibles.
Comment définir l'en-tête Permissions-Policy dans WordPress
Vous pouvez ajouter l'en-tête via la configuration de votre serveur web ou via une extension WordPress. Pour Apache, vous ajouteriez une ligne à votre fichier .htaccess :
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), bluetooth=()"Pour Nginx, l'équivalent va dans votre bloc serveur :
add_header Permissions-Policy "camera=(), microphone=(), geolocation=(), payment=(), usb=(), bluetooth=()" always;Des extensions de sécurité comme HTTP Headers, Really Simple Security ou Perfmatters offrent également des contrôles via l'interface pour définir l'en-tête Permissions-Policy sans toucher aux fichiers de configuration du serveur.
Ce que vérifie InspectWP
InspectWP analyse si votre site WordPress envoie un en-tête Permissions-Policy dans ses réponses HTTP. Si l'en-tête est manquant, le rapport signale cela comme un problème de sécurité car le contenu tiers intégré (publicités, widgets, iframes) peut être en mesure d'accéder à des fonctionnalités sensibles du navigateur comme la caméra, le microphone ou la géolocalisation sans aucune restriction. Le rapport affiche également la valeur brute de l'en-tête afin que vous puissiez vérifier quelles fonctionnalités sont actuellement restreintes.