Permissions-Policy
Utilisation
L’en-tête de réponse Permissions-Policy restreint les fonctionnalités du navigateur autorisées dans le cadre courant. Chaque politique associe une directive de fonctionnalité à une liste d’autorisation définissant quelles origines accèdent à la fonctionnalité.
Permissions-Policy: <directive>=<allowlist>Remarque
Une politique de départ recommandée désactive les fonctionnalités que le site n’utilise pas : Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), bluetooth=(). Les scanners de sécurité signalent l’absence d’en-tête Permissions-Policy. Définir une politique minimale résout ce constat sans affecter le fonctionnement du site.
Remarque
Le mécanisme Permissions-Policy était auparavant connu sous le nom de Feature Policy.
Directives
Le nom de la directive identifie la fonctionnalité du navigateur à contrôler. Voici une liste non exhaustive des directives normalisées :
Remarque
La directive interest-cohort servait à bloquer Federated Learning of Cohorts (FLoC). Google a abandonné FLoC en 2022 et a remplacé l’API par la Topics API. La directive interest-cohort a été retirée des implémentations des navigateurs.
Valeurs de la liste d’autorisation
La
Remarque
La directive unload bloque les gestionnaires d’événement unload pour l’origine. Définir Permissions-Policy: unload=() empêche le code propriétaire, les scripts tiers et les extensions de navigateur d’enregistrer des gestionnaires unload. Cela compte beaucoup pour les performances du cache avant-arrière (bfcache), car les gestionnaires unload empêchent le navigateur de mettre les pages en cache pour une navigation arrière et avant instantanée. Chrome déprécie progressivement les événements unload dans leur totalité, en commençant par les sites à fort trafic puis en étendant la mesure à tous les sites. Définir unload=() fait adhérer immédiatement à cette dépréciation et garantit l’éligibilité au bfcache, quel que soit le calendrier de déploiement.
Exemple
Dans l’exemple suivant, le serveur indique que la fonctionnalité geolocation doit être désactivée dans tous les contextes.
Permissions-Policy: geolocation=()Dans l’exemple suivant, le serveur indique que la fonctionnalité encrypted-media doit être désactivée pour toutes les origines sauf report.example.re.
Permissions-Policy: encrypted-media=("https://report.example.re")Dans l’exemple suivant, le serveur indique que la fonctionnalité microphone doit être désactivée pour toutes les origines sauf elle-même et celles dont l’origine est example.re.
Permissions-Policy: microphone=(self "https://example.re")Bloquer les gestionnaires unload pour améliorer l’éligibilité au bfcache. Cela empêche les scripts tiers et les extensions d’enregistrer des événements unload qui dégradent les performances de la navigation avant-arrière.
Permissions-Policy: unload=()Dépannage
Les violations de Permissions-Policy se manifestent silencieusement dans la plupart des cas : la fonctionnalité bloquée renvoie un état refusé ou lève une erreur, sans invite visible du navigateur.
Fonctionnalité bloquée dans une iframe faute d’attribut allow. Même lorsque la page parente autorise une fonctionnalité, les iframes intégrées ont besoin d’un attribut allow explicite pour y accéder. Ajoutez l’attribut à la balise iframe :
Geolocation, camera ou microphone ne fonctionnent plus après la mise en place de la politique. Une politique telle que Permissions-Policy: geolocation=() désactive la fonctionnalité pour toutes les origines, y compris la page elle-même. Pour n’autoriser la fonctionnalité que sur la même origine, utilisez geolocation=(self). Pour autoriser en plus une origine intégrée précise, utilisez geolocation=(self “https://maps.example.re”). Le navigateur n’invite jamais l’utilisateur pour une fonctionnalité que la politique a déjà refusée.
Le joker * ne fonctionne pas pour toutes les fonctionnalités. Certaines fonctionnalités ne prennent pas en charge la valeur * dans la liste d’autorisation et se limitent à des listes d’origines explicites. Lorsque * reste sans effet, indiquez chaque origine autorisée individuellement. Consultez la console du navigateur pour repérer les avertissements concernant des valeurs de liste d’autorisation non reconnues ou non prises en charge.
Migrer de Feature-Policy vers Permissions-Policy. L’en-tête historique Feature-Policy utilise une syntaxe différente : Feature-Policy: geolocation ‘self’ face à Permissions-Policy: geolocation=(self). Les navigateurs qui prennent en charge Permissions-Policy ignorent Feature-Policy lorsque les deux en-têtes sont présents. Mettez à jour le nom de l’en-tête et convertissez la syntaxe : remplacez les espaces par =, entourez les listes d’origines de parenthèses et supprimez les apostrophes autour de self et none (utilisez () au lieu de ‘none’).
Déboguer avec document.featurePolicy.allowsFeature(). Dans les navigateurs basés sur Chromium, ouvrez la console des DevTools et exécutez document.featurePolicy.allowsFeature(‘camera’) pour vérifier si une fonctionnalité est autorisée dans le contexte courant. L’appel renvoie true ou false. Pour les contextes d’iframe, passez l’origine en second argument : document.featurePolicy.allowsFeature(‘camera’, ‘https://embed.example.re’). Firefox utilise document.permissionsPolicy à la place de document.featurePolicy.