# Permissions-Policy (/fr/docs/web-security/policies/permissions-policy) 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. 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 : ```http Permissions-Policy: geolocation=(), camera=(), microphone=() ``` ## Comment fonctionne Permissions-Policy [#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 [#comment-configurer-permissions-policy] ```http 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 [#mode-report-only] ```http Reporting-Endpoints: pp-endpoint="https://.report.centralcsp.com" ``` ```http 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 [#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 [#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 [#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](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy) (voir les [headers de sécurité hérités](/fr/docs/web-security/policies/legacy-headers)). ## Risques [#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 [#recommandation] ```http Permissions-Policy: geolocation=(), camera=(), microphone=() ``` La [cheat sheet HTTP Headers de l'OWASP](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html) 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 [#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](/fr/docs/web-security/reporting-api/reports/permissions-policy-violation). CentralCSP collecte le [flux](/fr/docs/platform/monitoring/permissions-policy). ## Prise en charge par les navigateurs [#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 [#faq] ### Que fait Permissions-Policy ? [#que-fait-permissions-policy-] 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. ### Quelle est la différence entre Permissions-Policy et Feature-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. ## Voir aussi [#voir-aussi] * [rapport permissions-policy-violation](/fr/docs/web-security/reporting-api/reports/permissions-policy-violation) * [Headers de sécurité hérités](/fr/docs/web-security/policies/legacy-headers) * [Header Reporting-Endpoints](/fr/docs/web-security/reporting-api/headers/reporting-endpoints) * [Permissions-Policy expliqué](/fr/blog/permissions-policy-explained) * [Surveillance Permissions-Policy dans CentralCSP](/fr/docs/platform/monitoring/permissions-policy) ## Sources [#sources] * [MDN, Permissions-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Permissions-Policy) * [W3C, Permissions Policy](https://www.w3.org/TR/permissions-policy/) * [caniuse, Permissions Policy](https://caniuse.com/permissions-policy) * [OWASP HTTP Headers cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html)