Permissions-Policy : convertir entre en-tête et attribut allow

Qu’est-ce que Permissions Policy ?

Permissions Policy est la façon dont une page déclare quelles fonctionnalités du navigateur elle et ce qu’elle intègre ont le droit d’utiliser : la caméra, le micro, la géolocalisation, le plein écran, les demandes de paiement et quelques dizaines d’autres. Elle a remplacé Feature Policy et se livre de deux manières : en en-tête de réponse Permissions-Policy, qui couvre tout le document, et en attribut allow sur un iframe précis, qui ne couvre que ce cadre.

Les deux sont définies dans la même spécification du W3C et expriment la même idée : un nom de fonctionnalité suivi d’une liste d’origines autorisées à l’utiliser. Ce qui échappe facilement, c’est que la spécification écrit cette liste avec deux grammaires différentes, une par mécanisme de livraison, et qu’elles ne se ressemblent pas.

Ce convertisseur prend l’une ou l’autre écriture et produit celle qui manque, puis nomme chaque différence appliquée. C’est un outil de traduction et non un générateur de politique : il ne décide pas ce que votre politique devrait être et ne se prononce pas sur les fonctionnalités qu’il faudrait restreindre.

Comment l’utiliser

1. Indiquez de laquelle des deux écritures vous partez. Un attribut allow d’iframe, ou la valeur d’un en-tête Permissions-Policy. L’analyseur suit la grammaire de celle que vous choisissez : un en-tête collé comme attribut sera signalé comme incorrect plutôt qu’accepté sans bruit.
2. Collez la valeur seule. Sans le nom de l’attribut, sans les guillemets qui l’entourent, sans le nom du champ ni les deux-points de l’en-tête — seulement ce qu’il y a dedans. Les boutons d’exemple chargent cinq politiques, chacune choisie pour montrer une partie différente des deux grammaires.
3. Lisez les deux sorties et les trois panneaux en dessous. L’un énumère ce que l’analyseur a trouvé dans votre saisie. Un autre énumère ce qui ne survit pas au passage vers un en-tête. Un dernier nomme les quatre différences entre les grammaires, pour que vous voyiez lesquelles se sont appliquées.

Quatre différences entre les deux grammaires

La section 5.1 de la spécification donne à l’attribut une grammaire ABNF qui lui est propre ; la 5.2 dit que l’en-tête est au contraire un dictionnaire Structured Fields. Résultat : allow="geolocation 'self' https://example.com" et Permissions-Policy: geolocation=(self "https://example.com") sont la même politique écrite de deux façons, et quatre choses changent entre elles.

Les guillemets s’inversent. Les mots-clés sont entre apostrophes dans l’attribut et nus dans l’en-tête ; pour les origines c’est le contraire, nues dans l’attribut et sous forme de chaînes entre guillemets dans l’en-tête. Le séparateur change aussi : point-virgule entre directives dans l’attribut, virgule dans l’en-tête, puisque les membres d’un dictionnaire se séparent par des virgules. Et bloquer une fonctionnalité s’écrit avec le mot-clé none dans l’attribut mais avec une paire de parenthèses vides dans l’en-tête — le mot n’apparaît dans aucun en-tête.

La quatrième est celle qui demande de l’attention, car elle inverse le sens en silence au lieu d’échouer. Une fonctionnalité écrite sans rien derrière signifie l’inverse d’une grammaire à l’autre. Des parenthèses vides dans un en-tête forment une liste sans origine : personne. Un nom seul dans un attribut n’est pas vide du tout : la section 5.1 indique que la liste vaut alors 'src', c’est-à-dire l’origine de ce que cet iframe charge. Convertissez l’un en l’autre sans y prendre garde et une fonctionnalité bloquée devient autorisée.

Limites assumées

Il y a une chose qu’un attribut sait dire et pas un en-tête. Le mot-clé 'src' désigne l’origine du document indiqué dans l’attribut src de l’iframe, et un en-tête de réponse n’est rattaché à aucun iframe : il n’y a donc rien à désigner. La spécification est subtile ici et mérite une lecture lente : la section 4 dit que le mot-clé peut figurer dans le texte des listes aussi bien en en-tête que dans un attribut — ce n’est donc pas une erreur de syntaxe — et la section 9 ne le résout que lorsqu’une origine cible lui est fournie. Dans un en-tête, il s’analyse puis ne fait rien. Cet outil le signale comme une perte et non comme une erreur, parce que c’est ce que décrit la spécification.

Même chose pour les noms de fonctionnalité. La section 5.2 indique que si un membre du dictionnaire ne nomme pas une fonctionnalité prise en charge par le navigateur, le membre est ignoré lors du traitement. Une faute de frappe dans un en-tête ne produit d’avertissement nulle part : la directive n’a simplement aucun effet. Ce convertisseur vérifie que le nom est écrit légalement — lettres, chiffres et traits d’union — mais ne porte volontairement aucune liste de fonctionnalités prises en charge, car cette liste varie d’un navigateur et d’une version à l’autre et une copie périmée serait pire que rien.

Une dernière chose. La spécification cite la RFC 8941 pour la grammaire de l’en-tête, et la RFC 9651 a remplacé ce document en 2024. La nouvelle version ajoute deux types de données que cet en-tête n’utilise pas, déplace la grammaire vers une annexe informative et affine le traitement des échecs d’analyse ; elle ne change rien aux dictionnaires, aux jetons ni aux listes entre parenthèses. La citation est donc périmée, mais pas le comportement — et il faut le dire en entier, car chacune des deux moitiés prise seule induit en erreur.

Pourquoi est-ce gratuit ?

Ce sont deux petits analyseurs et deux sérialiseurs, et votre navigateur les exécute pendant que vous tapez. Aucun serveur n’intervient : il n’y a donc rien à facturer ni de compte à créer.

Rien n’est envoyé. La politique que vous collez reste dans cet onglet.