Mettre en place Permissions-Policy, l'en-tête HTTP qui remplace le Feature-Policy

Le 5 juin dernier, je vous ai proposé un tutoriel pour mettre en place l'en-tête HTTP Feature-Policy. Les choses ont quelque peu évolué depuis et l'en-tête a été renommé en Permissions-Policy. S'il s'agit d'un renommage de cet en-tête, conservant les mêmes directives, il ne suffit pas pour autant de renommer l'ancien en-tête en Permissions-Policy pour que cela soit opérationnel. Voyons donc ce qu'il convient de faire pour remplacer l'en-tête Feature-Policy par son successeur. Notons au passage que le tutoriel du jour peut aussi être utilisé pour mettre en place une Permissions-Policy en partant de zéro.

 

Permissions-Policy : un en-tête existant renommé

L'en-tête Permissions-Policy, n'est ni plus ni moins que l'en-tête Feature-Policy renommé. Dès lors, les fonctionnalités de ces deux en-têtes sont les mêmes. Je vous repartage donc ici leurs fonctionnalités. Cela vous servira notamment si vous souhaitez mettre en place l'en-tête Permissions-Policy en partant de zéro :

• accelerometer
• ambient-light-sensor
• autoplay 
• battery 
• camera
• display-capture
• document-domain
• encrypted-media
• fullscreen
• geolocation
• gyroscope
• layout-animations
• legacy-image-formats
• magnetometer
• microphone
• midi
• notifications
• oversized-images
• payment
• picture-in-picture
• publickey-credentials-get
• push
• speaker
• sync-xhr
• usb
• vibrate
• vr (encore actif, mais déprécié)
• wake-lock
• xr-spatial-tracking

Pour chacune des fonctionnalités ci-dessus, on va ensuite pouvoir indiquer nos directives, c'est-à-dire les comportements à adopter. Ces directives sont les suivantes :

• * pour permettre la fonctionnalité, quelle que soit son origine
• 'self' : pour permettre d'autoriser les fonctionnalités seulement si elles proviennent du même domaine
• src : permet de définir une source pour laquelle la fonctionnalité est activée
• () : pour interdire purement et simplement l'utilisation de la fonctionnalité

 

Pour rappel, cet en-tête vise à contrôler (autoriser ou restreindre) les fonctionnalités des navigateurs qui le prennent en compte lorsqu'ils servent le contenu de notre site. Le but final ici est bien évidemment d'éviter que des fonctionnalités inutiles pour le site soient exploitées de manière malicieuse.

Voyons maintenant comment en pratique mettre en place cet en-tête.

 

Implémenter l'en-tête Permissions-Policy sur son site web

Comme indiqué en introduction de ce billet, il ne suffit pas de remplacer Feature-Policy par Permissions-Policy pour que cela soit opérationnel. Si vous vous contentez de faire cela, alors vous aurez bien un en-tête Permissions-Policy, mais celui-ci contiendra des directives inopérantes, comme le montre la capture ci-dessous (oui oui, j'ai tenté l'expérience pour vous...).

 

Pour ceux qui ont déjà implémenté Feature-Policy, le plus simple est surement de commenter votre directive Feature avec le caractère dièse en début de ligne # et de repartir sur une nouvelle ligne. Cela permettra de conserver les anciennes directives le temps de les intégrer dans le nouvel en-tête. Pour implémenter l'en-tête Permissions-Policy, on va pouvoir agir, comme souvent, soit de manière générale sur le serveur web, soit de manière granulaire sur les sites web. Voyons donc rapidement ces deux méthodes.

 

Implémentation générale pour le serveur web apache2

Pour activer cet en-tête de manière globale sur un serveur web de type apache2, il convient d'éditer le fichier  /etc/apache2/conf-available/security.conf et d'y ajouter le Permissions-Policy sur une nouvelle ligne comme ceci :

Header set Permissions-Policy "accelerometer=(), geolocation=('self'), fullscreen=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), display-capture=('self')"

La syntaxe est donc la suivante : fonctionnalité=(ce qu'on autorise), fonctionnalité2=(ce qu'on autorise).  Dans le cas où l'on souhaite interdire complètement la fonctionnalité, il suffit de ne rien écrire entre les parenthèses.

 

Une fois que vous avez renseigné toutes vos directives, redémarrez votre serveur apache2 (un reload est peut-être suffisant, mais pour ma part je préfère un restart) : 

systemctl restart apache2

 

Implémentation au cas par cas pour un site web

Si votre serveur web héberge plusieurs sites, il est probable que vous souhaitiez implémenter cet en-tête de manière personnalisée sur chaque site. Et bien, c'est tout à fait possible. Pour cela, on va utiliser le fichier de déclaration de notre virtual host. Éditez donc le fichier contenant la configuration de votre vhost, et placez simplement votre directive avant la balise </VirtualHost> de la manière suivante :

<IfModule headers_module> 
Header set Permissions-Policy "accelerometer=(), geolocation=('self'), fullscreen=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), display-capture=('self')" 
</IfModule>

Ensuite, un petit restart et le tour est joué.

 

Mais il est également possible que vous n'ayez pas la main sur la configuration du serveur web hébergeant votre site. Dans ce cas, une implémentation est tout de même possible au travers du fichier .htaccess. Pour cela, il suffit d'ajouter nos directives dans la section mod_headers.c comme ceci :

<IfModule headers_module.c> 
Header set Permissions-Policy "accelerometer=(), geolocation=('self'), fullscreen=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), display-capture=('self')" 
</IfModule>

 

Le résultat

Quelle que soit la méthode utilisée, votre en-tête doit maintenant être fonctionnel et il est donc temps de vérifier ça en scannant à nouveau votre site web (ou l'un de vos sites web) avec SecurityHeaders.

Et bien pour ma part, comme vous pouvez le constater, j'ai récupéré mon A !! 🙂