# Verrouiller les fonctionnalités du navigateur avec Permissions-Policy et recevoir des reports (/fr/blog/permissions-policy-explained)
Une page que vous déployez charge des scripts tiers, des tags publicitaires et des
widgets intégrés, et chacun d'eux peut demander au navigateur la caméra, le
microphone ou la position de l'utilisateur. Le header de réponse
[`Permissions-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Permissions-Policy)
vous permet de décider quelles fonctionnalités la page et les iframes qu'elle
intègre ont le droit d'utiliser, et de couper celles dont vous n'avez pas besoin. C'est
un header de réponse : vous le définissez une fois sur le serveur, et le navigateur
l'applique à chaque requête.
## Ce que Permissions-Policy contrôle [#ce-que-permissions-policy-contrôle]
Les navigateurs exposent une longue liste de fonctionnalités que les scripts peuvent
appeler : caméra, microphone, géolocalisation, plein écran, lecture automatique, l'API
Payment Request, accéléromètre, USB, entre autres. Chacune est régie par une politique
nommée. `Permissions-Policy` vous permet d'indiquer, fonctionnalité par fonctionnalité, qui
a le droit de l'utiliser : la page elle-même, des origines précises, tout le monde, ou personne.
La plupart des fonctionnalités valent `self` par défaut : votre propre origine peut s'en
servir, mais pas les iframes cross-origin que vous intégrez, tant que vous ne leur
accordez pas l'accès. Définir le header vous permet de resserrer encore (refuser une
fonctionnalité d'emblée) ou d'ouvrir délibérément (autoriser une intégration de
confiance). Refuser une fonctionnalité que
vous n'utilisez jamais réduit la surface d'attaque : un script tiers compromis ne peut
pas demander à l'utilisateur sa position si la page a coupé la géolocalisation.
C'est de l'observabilité et du contrôle côté navigateur, pas un pare-feu. Le
navigateur applique la politique ; rien ne proxie ni ne réécrit la requête.
Une réserve sur la compatibilité : en pratique, seul Chromium applique le header.
Firefox et Safari implémentent le modèle de l'attribut `allow` des iframes pour
certaines fonctionnalités, mais pas le header de réponse `Permissions-Policy`.
Considérez le header comme une couche d'application et de reporting propre à Chromium, et
appuyez-vous sur l'attribut `allow` pour un contrôle par frame qui vaut sur tous les
navigateurs.
## La syntaxe du header [#la-syntaxe-du-header]
Le header est une liste d'entrées `feature=allowlist` séparées par des virgules.
L'allowlist se place entre parenthèses et liste les origines autorisées à utiliser cette
fonctionnalité.
```http
Permissions-Policy: camera=(), microphone=(), geolocation=(self)
```
Cet exemple coupe la caméra et le microphone partout (une allowlist vide `()` signifie
aucune origine du tout), et autorise la géolocalisation uniquement sur votre propre
origine.
Les tokens d'allowlist sont :
* `()` refuse la fonctionnalité à tout le monde, y compris votre propre page.
* `self` autorise votre propre origine uniquement.
* `*` autorise toutes les origines, votre page et toute iframe intégrée.
* `"https://example.com"` autorise une origine précise (entre guillemets). Listez-en
plusieurs entre les parenthèses, séparées par des espaces.
```http
Permissions-Policy: fullscreen=(self "https://embed.example.com"), autoplay=()
```
Ici le plein écran est autorisé pour votre page et une intégration de confiance, et la
lecture automatique est coupée pour tout le monde. Choisissez l'allowlist la plus étroite
possible sans casser la page : partez de `()` ou `self` et n'ajoutez une origine
que lorsqu'une intégration a réellement besoin de la fonctionnalité.
## Comment il se rapporte à l'attribut allow des iframes [#comment-il-se-rapporte-à-lattribut-allow-des-iframes]
Le header régit votre page de premier niveau et fixe la limite extérieure de ce que
n'importe quelle iframe peut recevoir. L'attribut `allow` des iframes est l'autre moitié :
il délègue une fonctionnalité à une frame intégrée précise, dans les limites de ce que la
politique au niveau de la page permet déjà.
```html
```
Pour que cette iframe obtienne réellement la géolocalisation, deux conditions doivent être
réunies : la `Permissions-Policy` de votre page doit autoriser l'origine de l'iframe (par exemple
`geolocation=(self "https://maps.example.com")`), et l'attribut `allow` doit déléguer la
fonctionnalité à la frame. L'attribut ne peut que restreindre ou transmettre ce que le
header autorise déjà ; il ne peut jamais accorder une fonctionnalité que la politique au
niveau de la page a refusée. Voyez le header comme le plafond, et l'attribut `allow` comme
la délégation frame par frame en dessous.
## Il remplace le Feature-Policy déprécié [#il-remplace-le-feature-policy-déprécié]
`Permissions-Policy` est le successeur de l'ancien header `Feature-Policy`. Si vous servez
encore `Feature-Policy`, il est temps de le retirer ; nous l'évoquons avec les autres
headers à abandonner dans
[security headers hérités à abandonner](/fr/blog/legacy-security-headers-to-retire).
Le renommage s'est accompagné d'un changement de syntaxe. L'ancien header utilisait une
liste séparée par des espaces avec des mots-clés entre guillemets :
```diff
-Feature-Policy: geolocation 'self'; camera 'none'
+Permissions-Policy: geolocation=(self), camera=()
```
La structure est passée de `feature 'value'` séparé par des points-virgules à
`feature=(allowlist)` séparé par des virgules, `'self'` est devenu `self` (sans
guillemets), et `'none'` est devenu une allowlist vide `()`. Les origines sont toujours
entre guillemets, mais les noms de fonctionnalités et les mots-clés ne le sont plus.
## Recevoir des reports permissions-policy-violation [#recevoir-des-reports-permissions-policy-violation]
Une politique qui refuse une fonctionnalité est plus utile quand vous pouvez voir ce qui a
tenté de l'utiliser. Quand un script ou une iframe tente une fonctionnalité que la
politique bloque, le navigateur peut émettre un
[report `permissions-policy-violation`](/fr/docs/web-security/reporting-api/reports/permissions-policy-violation)
via la Reporting API, nommant la fonctionnalité bloquée et d'où venait la tentative. Cela
transforme un refus silencieux en signal : vous apprenez quel tiers cherche à atteindre la
caméra, et si une politique resserrée casserait une intégration légitime.
Pour recevoir ces reports, vous déclarez un endpoint avec le header `Reporting-Endpoints`,
le même câblage que pour n'importe quel autre report de navigateur. Nous le détaillons de
bout en bout dans [comment mettre en place la Reporting API](/fr/blog/how-to-set-up-the-reporting-api).
```http
Reporting-Endpoints: default="https://.report.centralcsp.com"
```
Pour tester une politique sans bloquer, envoyez-la sur le header
`Permissions-Policy-Report-Only` au lieu de celui qui impose. Il signale chaque tentative
d'utilisation sans la refuser. Sélectionnez l'endpoint de reporting avec un paramètre
`report-to=` par directive, pas un token dans l'allowlist de la fonctionnalité.
CentralCSP collecte les reports `permissions-policy-violation` à côté de vos reports CSP
et autres reports de navigateur, pour que vous puissiez surveiller quelles
fonctionnalités les tiers cherchent à atteindre et alerter dès que quelque chose de nouveau
apparaît, sans avoir à construire de récepteur vous-même. Voyez comment nous
[agrégeons chaque report de navigateur](/platform/monitoring).
## Par où commencer [#par-où-commencer]
Auditez quelles fonctionnalités puissantes votre page et ses intégrations utilisent
réellement, refusez le reste avec une allowlist vide, et câblez le reporting pour
découvrir quand quelque chose tente une fonctionnalité que vous avez coupée. Puis observez
les reports pendant une semaine avant de verrouiller la politique pour de bon.
[Commencez à collecter les reports Permissions-Policy](/register).
## Articles liés [#articles-liés]
* [Référence du header Permissions-Policy](/fr/docs/web-security/policies/permissions-policy)
* [Security headers hérités à abandonner](/fr/blog/legacy-security-headers-to-retire)
* [Comment mettre en place la Reporting API](/fr/blog/how-to-set-up-the-reporting-api)
* [Qu'est-ce que NEL, le network error logging depuis le navigateur](/fr/blog/what-is-nel-network-error-logging)
## Sources [#sources]
* [MDN, header 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-1/)
* [MDN, aperçu de Permissions Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Permissions_Policy)