Permissions-Policy, contrôler les fonctionnalités et signaler les violations

Permissions-Policy autorise ou refuse des fonctionnalités du navigateur comme la caméra, le microphone et la géolocalisation, par document et par frame.

Permissions-Policy permet à un site de décider quelles fonctionnalités et API du navigateur peuvent être utilisées, dans le document principal et dans les frames embarquées. Vous pouvez couper net la géolocalisation, la caméra, le microphone et bien d'autres fonctionnalités, ou ne les autoriser que pour des origines précises, ce qui réduit la surface d'attaque et d'exposition de la vie privée accessible à une page et à ses tiers.

Disponibilité limitée

Le header Permissions-Policy est limité à Chromium (Chrome et Edge), et les données de compatibilité navigateur le marquent encore expérimental. Firefox et Safari ne prennent en charge que le modèle de l'attribut allow sur iframe pour certaines fonctionnalités. Envoyer le header vaut quand même la peine en défense en profondeur ; les navigateurs qui ne le prennent pas en charge l'ignorent sans dommage.

La base OWASP refuse net les trois fonctionnalités les plus sensibles pour la vie privée :

Permissions-Policy: geolocation=(), camera=(), microphone=()

Comment fonctionne Permissions-Policy

Le header est une liste d'entrées directive=allowlist séparées par des virgules, où la directive est un nom de fonctionnalité et l'allowlist indique quelles origines peuvent l'utiliser. Une allowlist vide désactive la fonctionnalité partout ; (self) la limite à votre propre origine.

Comment configurer Permissions-Policy

Permissions-Policy: geolocation=(), camera=(self)

Allowlist	Statut	Signification
`*`	❌ Risqué	Toutes les origines, y compris les frames tierces, peuvent utiliser la fonctionnalité.
`()`	✅ Bon	La fonctionnalité est désactivée partout.
`(self)`	✅ Bon	Seule votre propre origine peut l'utiliser.
`(src)`	✅ Bon	Dans un contexte `allow` sur iframe, l'origine propre de la frame.
`("https://a.example")`	✅ Bon	Des origines explicites entre guillemets (séparées par des espaces ; combinables avec `self`).
`("https://*.example.com")`	✅ Bon	Une origine avec joker couvrant les sous-domaines.

* et () doivent apparaître seuls. L'exemple ci-dessus désactive entièrement la géolocalisation et n'autorise la caméra que sur votre propre origine.

Les fonctionnalités qui méritent le plus d'être restreintes sont les plus sensibles pour la vie privée : camera, microphone, geolocation, fullscreen, payment, usb, display-capture et autoplay, plus les opt-outs publicitaires browsing-topics et interest-cohort.

Mode Report-Only

Reporting-Endpoints: pp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"

Permissions-Policy-Report-Only: geolocation=();report-to=pp-endpoint

Report-Only révèle quelles fonctionnalités seraient bloquées avant que vous appliquiez la politique, pour ne pas casser un usage légitime d'une fonctionnalité dans une frame.

Ce contre quoi il protège

L'usage indésirable de fonctionnalités, par votre propre page ou, plus souvent, par une frame tierce : caméra, microphone, géolocalisation, paiement et autres API sensibles. Les restreindre réduit à la fois l'exposition de la vie privée et la surface qu'un attaquant (ou un tiers négligent) peut atteindre.

Configurations non sûres à éviter

Accorder une fonctionnalité avec * autorise toutes les origines, y compris les frames tierces, à l'utiliser. Préférez () pour désactiver, ou (self) pour limiter à votre propre origine.

Refusez par défaut les fonctionnalités que vous n'utilisez pas, et n'ajoutez des origines qu'au fur et à mesure des besoins.

Contournements et limites connus

Le header lui-même n'est pas appliqué hors de Chromium : Firefox et Safari n'implémentent que le modèle de l'attribut allow sur iframe pour certaines fonctionnalités, donc ce n'est pas encore un contrôle pleinement multi-navigateurs. Traitez le header comme une défense en profondeur sur Chromium et utilisez l'attribut allow sur iframe pour les cas multi-navigateurs. Permissions-Policy est le successeur standardisé du header déprécié Feature-Policy (voir les headers de sécurité hérités).

Risques

Trop restreindre peut casser une fonctionnalité légitime dans une frame oubliée (une carte embarquée qui a besoin de la géolocalisation, un appel vidéo qui a besoin de la caméra). Testez avec Report-Only et surveillez les violations avant d'appliquer.

Recommandation

Permissions-Policy: geolocation=(), camera=(), microphone=()

La cheat sheet HTTP Headers de l'OWASP recommande de refuser les fonctionnalités sensibles que vous n'utilisez pas, en commençant par la géolocalisation, la caméra et le microphone. Étendez la liste aux autres fonctionnalités ci-dessus selon ce que votre page permet, et n'accordez une origine que lorsqu'une frame précise en a besoin.

Reporting

Un paramètre report-to= par directive route les violations de cette fonctionnalité vers un endpoint nommé, et le navigateur émet le rapport permissions-policy-violation. CentralCSP collecte le flux.

Prise en charge par les navigateurs

Un standard W3C, mais le header est limité à Chromium (Chrome et Edge, avec une couverture partielle des fonctionnalités), et les données de compatibilité navigateur le marquent expérimental. Firefox et Safari ne prennent en charge que le modèle de l'attribut allow sur iframe pour certaines fonctionnalités. Le reporting est lui aussi limité à Chromium.

FAQ

Que fait Permissions-Policy ?

Quelle est la différence entre Permissions-Policy et Feature-Policy ?

Ce sont le même mécanisme sous deux noms. Permissions-Policy est le successeur standardisé du header déprécié Feature-Policy, qui était son ancien nom. Utilisez Permissions-Policy désormais, et recourez à l'attribut allow sur iframe pour les cas multi-navigateurs que le header ne couvre pas encore hors de Chromium.

Permissions-Policy