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.

Justegeek.fr repassé B sur securityheaders à cause de l'absence de Permissions-Policy

Justegeek.fr repassé B sur securityheaders à cause de l'absence de Permissions-Policy

 

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...).

L'en-tête Permissions-Policy possède une syntaxe différente de Feature-Policy

L'en-tête Permissions-Policy possède une syntaxe différente de Feature-Policy

 

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.

L'en-tête Permissions-Policy en place sur Justegeek.fr

L'en-tête Permissions-Policy en place sur Justegeek.fr

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

 

Sandstorm

Sandstorm

Ingénieur Systèmes passionné d'informatique et de High-Tech, Sandstorm a créé JusteGeek.fr en 2013. Il aime les geekeries en tout genre. "Si un produit s'allume c'est un bon point. S'il est connecté, c'est encore mieux !"

Vous aimerez aussi...

7 réponses

  1. Avatar ckrisL dit :

    J'ai suivis tous les tutos et ça m'aide beaucoup à comprendre et sécuriser Apache.

  2. Avatar Mrdoc dit :

    Pour la petite histoire...
    j'ai découvert ton site récemment car comme toi j'ai découvert un peu par hazard le monde caché des ces foutus "Headers" il y' a 2..3 jours.
    Du coup je suis partie en guerre contre toutes ces foutus failles. J'ai résolu une bonne parti de mes soucie avec le Plugin HTTP Headers.
    Je ne sais pas si tu connais ?! Je tiens à précisé que je ne suis pas un codeur juste un curieux de nature.

    Mais quand je suis arrivé à cette merde de CSP qui à réussi à me faire refuser l'accès à mon site, c'est la que j'ai compris la merde que c'était,
    du coup après ça j'ai commencer mon voyage pour découvrir la solution de paramétrage idéal CSP et j'ai découvert divers site dont le tiens !
    Même si j'avais déjà fait pas mal de réglages tes articles sur le sujet à apporter pas mal de réponses. Bref du bon boulot dans la présentation et la pédagogie. Faire du bon taf c'est pas facile alors du coup je te félicite pour ça.

    J'espère que tu m'en veux pas trop pour le "tutoiement", mais tant que le respect est là, de mon point de vue tout roule.

    Mon commentaire supplémentaire à cet article ne va pas arranger la chose niveau pression, mais c'est dans un but positif pour nous TOUS....

    alors c'est quand que tu t'attaque à Broly ?! je veux parler bien sur parler de Content-Security-Policy" ! 😎

    A un moment donné ou à un autre, faut qu'on (internet FR) lui foute sur la geulle à cet enfoirée de CSP avec un bon petit nouvel article cool non ?!!

    • Sandstorm Sandstorm dit :

      Salut ! Merci pour ton commentaire... Bon vous êtes vraiment trop à me le demander, cela ne peut plus durer. Je vais tenter de faire ça lors de mes prochaines vacances ! (sans doute en mars/avril).

      • Avatar MrDoc dit :

        Très bonne nouvelle. Prend ton temps (vue la complexité du machin) pour nous pondre un truc aussi cool que le reste.
        Comme j'ai dit plus haut j'ai utilisé le plugin HTTP HEADERS....du coup tu nous dira ce qu'on peut paramétré et ce qu'on doit éviter...bref....Tu verra je te fais confiance.

        PS: si jamais tu veux faire ça en vidéo, je te conseille le logiciel CAMTASIA....car il est propre et facile à prendre en main au point d'en devenir presque addict ^^.

        à bientôt !

      • Avatar stephanie sec dit :

        Bonjour Super! je n'attends plus que celui ci, et merci pour les autres, ils fonctionnent parfaitement dans le .htacess sauf chez one & one IONOS pourtant en apache, je me demande pourquoi, auriez vous une idée?
        Merci pour vos articles, je suis graphiste webdesigner et cela me permet d'être plus secure pour mes clients.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.