Ce que l’en-tête Permissions-Policy peut réellement verrouiller

La version courte

Permissions-Policy est un en-tête de réponse HTTP qui permet à un site de limiter l’accès à certaines fonctionnalités du navigateur : caméra, microphone, géolocalisation, plein écran, paiement, capteurs, et une longue liste de petites API.

Ce n’est pas un bouclier de confidentialité général. Il n’arrêtera pas tout le suivi, ne bloquera pas les cookies, n’empêchera pas les requêtes réseau et ne rendra pas le JavaScript tiers sûr. Ce qu’il fait bien est plus restreint, mais reste précieux : réduire les capacités du navigateur disponibles pour vos propres pages et pour les frames intégrées.

C’est important parce que les sites web modernes sont assemblés à partir d’extraits d’analytics, d’intégrations média, de widgets de chat, de gestionnaires de consentement, de scripts publicitaires, de cartes, de flux de paiement et d’expériences internes. La plupart de ces composants n’ont pas besoin d’accéder à de puissantes API d’appareil. Une bonne policy rend cela explicite.

Si vous examinez déjà les en-têtes en production, associez ce travail à une vérification directe de la réponse réelle. Notre guide sur le débogage des redirections et des en-têtes HTTP en production couvre l’habitude qui compte ici : inspecter ce que le navigateur reçoit réellement, et non ce que votre fichier de configuration indique comme devant se produire.

Ce que Permissions-Policy contrôle

L’en-tête contrôle l’accès à des fonctionnalités nommées du navigateur. La liste exacte évolue avec le temps parce que les API des navigateurs évoluent, mais les directives courantes incluent :

• camera
• microphone
• geolocation
• fullscreen
• payment
• usb
• bluetooth
• accelerometer
• gyroscope
• magnetometer
• screen-wake-lock
• clipboard-read
• clipboard-write
• publickey-credentials-get
• interest-cohort dans d’anciennes discussions, désormais surtout historique

Une directive peut autoriser une fonctionnalité pour personne, pour l’origine actuelle ou pour des origines sélectionnées. Par exemple :

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

Cela signifie que la caméra et le microphone sont désactivés pour le document et ses contextes de navigation imbriqués, tandis que la géolocalisation est autorisée uniquement pour la même origine.

Un exemple plus permissif :

Permissions-Policy: geolocation=(self "https://maps.example"), fullscreen=(self "https://video.example")

Cela permet à votre propre origine et à un fournisseur de cartes nommé d’utiliser la géolocalisation, et à votre propre origine ainsi qu’à un fournisseur vidéo de demander le plein écran.

La policy est évaluée par le navigateur. Si une fonctionnalité est refusée, le JavaScript qui utilise cette API devrait échouer ou se comporter comme si elle était indisponible. Le mode d’échec exact dépend de l’API. Parfois, une promise est rejetée. Parfois, une capacité semble simplement inutilisable.

Ce qu’il peut verrouiller sur vos propres pages

Sur les pages first-party, Permissions-Policy est surtout utile comme garde-fou. Il réduit le rayon d’impact du code accidentel ou inattendu.

Une page marketing, par exemple, n’a probablement pas besoin du microphone, de la caméra, du Bluetooth, de l’USB, des capteurs de mouvement ou des API de paiement. Vous pouvez refuser ces fonctionnalités globalement :

Permissions-Policy: camera=(), microphone=(), bluetooth=(), usb=(), payment=(), accelerometer=(), gyroscope=(), magnetometer=()

Cela ne rend pas tous les scripts de la page dignes de confiance. Cela signifie bien que si une expérience de tag manager, une dépendance compromise ou un widget collé tente d’appeler une API restreinte, le navigateur ne devrait pas lui accorder l’accès.

Pour les équipes comptant de nombreux contributeurs, c’est une valeur par défaut utile. Cela déplace la conversation d’une confiance vague vers une capacité explicite. Si une future fonctionnalité a réellement besoin de la caméra, quelqu’un devra modifier la policy et expliquer pourquoi.

C’est le bon type de friction.

Ce qu’il peut verrouiller dans les iframes

L’en-tête devient particulièrement utile autour du contenu intégré.

Les navigateurs traitent déjà les iframes comme des contextes de navigation séparés, mais le contenu tiers intégré peut tout de même demander des fonctionnalités puissantes s’il y est autorisé par la policy et les attributs de l’iframe. Permissions-Policy permet à la page parente de fixer un plafond.

Par exemple, si votre page intègre un lecteur vidéo, un widget de support et une carte, vous pouvez éviter de donner à chaque frame l’accès à toutes les fonctionnalités. Vous pourriez autoriser le plein écran uniquement pour la frame vidéo et la géolocalisation uniquement pour la frame de carte.

Il y a deux couches à comprendre :

1. L’en-tête HTTP Permissions-Policy définit la policy pour le document.
2. L’attribut allow de l’iframe peut déléguer des fonctionnalités spécifiques à une frame, mais uniquement dans les limites permises par la policy parente.

Une iframe simple pourrait ressembler à ceci :

<iframe src="https://video.example/embed/123" allow="fullscreen"></iframe>

Si votre en-tête refuse entièrement le plein écran, l’attribut de l’iframe ne peut pas contourner ce refus. Si votre en-tête autorise le plein écran pour cette origine, l’attribut de l’iframe peut le déléguer.

Cette hiérarchie est l’une des raisons pour lesquelles l’en-tête mérite d’être utilisé. Il donne aux équipes plateforme ou sécurité un moyen de fixer des limites à l’échelle du site, tout en permettant aux équipes produit d’activer des intégrations spécifiques lorsque nécessaire.

Ce qu’il ne peut pas verrouiller

C’est ici que les équipes surestiment parfois l’en-tête.

Permissions-Policy ne remplace pas une content security policy. Il ne décide pas quels scripts peuvent se charger. Il n’empêche pas un script d’envoyer des données sur le réseau. Il ne nettoie pas le HTML. Il n’empêche pas le XSS. Il ne bloque pas le spam de formulaire. Si l’abus de formulaire est le problème, commencez par les mécanismes décrits dans pourquoi votre formulaire de contact est votre plus grande responsabilité en matière de spam, pas par cet en-tête.

Il ne remplace pas non plus la gouvernance des cookies. Les cookies, le local storage, le consentement, les intégrations tierces et les protections anti-suivi des navigateurs sont des sujets distincts. Si vous examinez largement les contrôles de confidentialité, le paysage des cookies mérite son propre passage en revue ; les changements pratiques sont couverts dans ce qui a changé pour les cookies en 2026 et quoi faire à ce sujet.

Plus important encore, Permissions-Policy ne rend pas le JavaScript tiers privé. Si vous chargez un script tiers dans votre page first-party, il s’exécute généralement avec les privilèges de votre page, sous réserve des autres contraintes du navigateur et de vos en-têtes de sécurité. Refuser l’accès à la caméra est une bonne chose. Cela n’empêche pas ce script de lire le contenu du DOM, d’observer les actions de l’utilisateur ou d’effectuer des requêtes réseau autorisées.

Pour cela, vous avez besoin d’autres contrôles : sélection rigoureuse des fournisseurs, CSP, iframes sandboxées, Subresource Integrity lorsque c’est applicable, minimisation des données, et des revues ennuyeuses mais nécessaires.

Une policy par défaut raisonnable

Il n’existe pas d’en-tête universel adapté à tous les sites, mais la plupart des sites de contenu et de marketing peuvent commencer de manière restrictive.

Une première passe raisonnable :

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), bluetooth=(), accelerometer=(), gyroscope=(), magnetometer=(), screen-wake-lock=()

Puis ne réactivez que ce que le site utilise réellement.

Par exemple :

• Une boutique utilisant Payment Request API peut avoir besoin de payment=(self).
• Un localisateur d’adresses peut avoir besoin de geolocation=(self) ou d’une origine de carte de confiance.
• Une application de conférence peut avoir besoin de camera=(self) et microphone=(self).
• Un site très axé sur la vidéo peut avoir besoin de fullscreen=(self "https://trusted-video.example").

L’important n’est pas de copier une policy énorme depuis une checklist et de considérer le travail terminé. Commencez par votre inventaire de fonctionnalités. Quelles pages ont besoin de quelles capacités du navigateur ? Quelles intégrations ont besoin d’une délégation ? Quelles fonctionnalités seraient surprenantes si elles étaient demandées ?

Comment déployer sans casser les choses

Déployez cela comme n’importe quel autre en-tête de production : délibérément.

1. Inventorier l’utilisation des fonctionnalités

Recherchez dans votre base de code les appels aux API du navigateur comme getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB et les API de wake lock.

Vérifiez ensuite les intégrations tierces. La documentation des fournisseurs de vidéo, de cartes, de paiement et d’identité mentionne souvent les valeurs allow d’iframe requises.

2. Commencer dans un environnement à faible risque

Ajoutez un en-tête restrictif en staging et testez les parcours principaux. Prêtez attention aux messages de la console du navigateur. Les navigateurs signalent souvent lorsqu’une fonctionnalité est bloquée par la permissions policy.

3. Utiliser des policies propres aux pages lorsque nécessaire

N’imposez pas une seule policy globale si votre produit comporte des types de pages très différents. Un blog, un checkout, une page de carte et une salle vidéo ont probablement besoin de capacités différentes.

La plupart des serveurs web, frameworks et plateformes edge peuvent définir des en-têtes conditionnellement selon le chemin. C’est souvent plus propre que d’affaiblir l’ensemble du site pour une seule fonctionnalité.

4. Vérifier la réponse réelle

Les en-têtes peuvent être ajoutés, remplacés, dupliqués ou supprimés par des CDN, reverse proxies, serveurs applicatifs et middlewares. Vérifiez la réponse finale dans les DevTools du navigateur ou avec des outils en ligne de commande.

Testez également les contextes intégrés. Le fait qu’une page de niveau supérieur semble correcte ne garantit pas qu’une iframe a reçu la délégation que vous vouliez.

5. Documenter les exceptions

Chaque fonctionnalité autorisée devrait avoir un propriétaire et une raison. Cela paraît bureaucratique jusqu’à six mois plus tard, lorsque plus personne ne se souvient pourquoi geolocation a été ouvert à un domaine fournisseur qui n’apparaît plus sur la page.

Erreurs de syntaxe courantes

La syntaxe moderne de l’en-tête est compacte, mais il est facile de se tromper légèrement.

Utilisez des parenthèses vides pour refuser une fonctionnalité :

Permissions-Policy: microphone=()

Utilisez self pour l’origine actuelle :

Permissions-Policy: geolocation=(self)

Utilisez des origines entre guillemets pour des origines externes spécifiques :

Permissions-Policy: fullscreen=(self "https://video.example")

Évitez de vous appuyer sur d’anciens exemples Feature-Policy, sauf si vous prenez intentionnellement en charge un comportement hérité. L’ancien en-tête utilisait une syntaxe différente et ce n’est pas autour de lui que vous devriez concevoir aujourd’hui.

Rappelez-vous aussi que la prise en charge par les navigateurs varie selon les directives. Un navigateur peut prendre en charge l’en-tête sans prendre en charge une directive de fonctionnalité particulière. C’est normal. Traitez l’en-tête comme une mesure de défense en profondeur, et non comme votre seul contrôle de confidentialité ou de sécurité.

<!-- tool-cta:start -->

💡 Essayez ceci : Vérifiez que votre Permissions-Policy est transmise comme prévu avec Get Headers, qui affiche les en-têtes de réponse bruts envoyés par votre serveur.

<!-- tool-cta:end -->

La valeur pratique pour la confidentialité

La valeur de Permissions-Policy pour la confidentialité n’est pas de rendre un site anonyme ou exempt de trackers. Ce n’est pas le cas.

Sa valeur est de réduire l’accès à des capacités sensibles du navigateur. Localisation, caméra, microphone, capteurs d’appareil, API de matériel local et flux de paiement sont puissants. La plupart des pages n’en ont pas besoin. Beaucoup de composants intégrés ne devraient jamais pouvoir les demander.

C’est une réelle amélioration. Cela réduit les prompts accidentels, limite l’exposition inutile des capacités et donne à votre équipe un artefact concret à examiner lorsque de nouvelles fonctionnalités sont livrées.

La meilleure version de cet en-tête est ennuyeuse : restrictive par défaut, assouplie uniquement lorsqu’une fonctionnalité visible par l’utilisateur l’exige, et testée dans le cadre du processus de release normal.