Contrôlez les fonctionnalités et API web avec les Feature Policy

Mathieu Chartier Programmation 0 commentaire

Google présente l'entête HTTP (header) Feature-Policy

Google a émis un nouveau brouillon (draft) auWeb Platform Incubator Community Group (WICG) afin d'envisager l'usage d'un nouvel entête HTTP appelé Feature Policy. L'objectif est de pouvoir activer ou désactiver volontairement des fonctionnalités ou API du navigateur web. Ainsi, il sera plus simple d'éviter certains bugs ou de mieux protéger les sites web contre certains risques de sécurité...

Qu'est-ce que le WICG ?

Le WICG est un collectif créé en juillet 2015 qui vise à proposer et discuter autour de nouvelles fonctionnalités et alternatives pour les plates-formes web de demain. Il ne s'agit donc pas du W3C ou d'un quelconque standard officiel. Toutefois, certaines avancées du WICG finissent parfois par être implémentées dans les navigateurs ou solutions web. Rappelons que le W3C n'est qu'une association à but non lucratif qui fournit des principes de développement (qu'il est recommandé de suivre), et même s'il a du poids dans le Web depuis 1994, il n'est pas plus "officiel" que le WICG pourrait l'être. Par conséquent, les navigateurs peuvent très bien intégrés des éléments qui ne sont pas fournis par le W3C à l'origine.

Initié par Google, le projet est déjà évoqué dans la documentation officielle de la société, avec de bons exemples d'usage à la clé. L'idée de l'entête Feature Policy est d'offrir aux développeurs une certaine souplesse dans l'usage ou non de fonctionnalités ou API de navigateurs. Que ce soit par souci de performance ou de sécurité, il est toujours intéressant de pouvoir contrôler, activer ou désactiver des API ou fonctionnalités. Le brouillon du WICG résume bien les possibilités génériques d'un tel système :

  • Possibilité de désactiver de manière sélective l'accès à certaines fonctionnalités ou API du navigateur pour verrouiller une application. Cela permet d'éviter de mauvais usages en interne qui pourrait nuire aux performances notamment, voire par des tierces parties mal intentionnées (risques pour la sécurité).
  • Possibilité d'activer des fonctionnalités et API désactivées par défaut dans un navigateur. Cela permet de pouvoir faire fonctionner une application ou un site même si une fonctionnalité est désactivée par défaut dans le navigateur, uniquement dans son propre contexte d'utilisation.
  • Possibilité de modifier quelque peu le comportement de certaines fonctionnalités.

Concrètement, la documentation de Google fournit des exemples d'usage des Feature Policy, qui ne sont pas négligeables en effet :

  • modifiez le comportement par défaut de l'autoplay sur les vidéos mobiles et tierces (lancement automatique des vidéos au chargement des pages) ;
  • restreindre un site contre l'usage d'API sensibles comme une camera ou un microphone (qui peuvent être détournées et devenir des risques pour la sécurité des usagers) ;
  • autoriser les iframes à utiliser l'API en plein écran (fullscreen) ;
  • bloquer l'utilisation d'API obsolètes comme XHR synchrone et document.write(), parfois à risque ;
  • assurez que les images sont correctement dimensionnées et qu'elles ne sont pas trop grandes pour la fenêtre d'affichage afin de booster les performances et l'ergonomie générale.

Comment utiliser les Feature Policy ?

Rien de très compliqué dans l'usage des Feature Policy, et c'est bien là tout l'intérêt du système. Deux méthodes permettent de mettre en place une "stratégie de fonctionnalité" :

  • utiliser l'entête HTTP Feature-Policy ;
  • intégrer l'attribut allow dans les iframes (pour autoriser le plein écran).

L'entête HTTP fonctionne à partir du schème suivant : Feature-Policy: <feature> <allow list origin(s)>. En d'autres termes, il faut indiquer la fonctionnalité visée, puis les autorisations et restrictions d'utilisation. Il existe quatre types de permissions :

  • L'étoile "*" permet d'autoriser l'usage complet des fonctionnalités, et même dans des iframes imbriquées dans d'autres sites web. C'est le cas par défaut.
  • "self" autorise l'usage dans les pages et iframes à condition que l'origine soit identique (même domaine). Par conséquent, un site externe ne pourra pas utiliser certaines fonctionnalités si la page est intégrée via une iframe, etc.
  • "none" bloque l'accès aux fonctionnalités.
  • <origin(s)> permet d'indiquer des URL autorisées pour l'usage de fonctionnalités ou API d'un site. Seules ces adresses pourront donc en profiter.

Voici trois exemples d'usage des Feature Policy :

  • Feature-Policy: geolocation 'self' https://example.com => Autorise l'accès à la géolocalisation uniquement pour l'application en elle-même et aux pages du domaine example.com.
  • Feature-Policy: vibrate 'none'; geolocation 'none' => Bloque l'accès aux fonctions de vibration et à la géolocalisation dans une application.
  • Feature-Policy: camera https://other.com; microphone https://other.com => Si nous sommes par exemple sur le site example.com, cet entête HTTP permet de bloquer l'usage de la webcam et du microphone sur le site, mais de l'autoriser pour les pages du domaine other.com.

Ajoutons à cela qu'il est possible d'utiliser l'attribut "allow" dans les iframe, et donc d'autoriser ponctuellement des fonctionnalités par ce biais :

  • allow="fullscreen" placé dans une iframe permet d'autoriser l'usage en plein écran de l'iframe.
  • Couplé à un entête Feature-Policy: geolocation 'self', l'attribut allow="geolocation" dans une iframe d'origine différente permet par exemple de ne pas restreindre l'accès à la localisation dans ce domaine externe. D'autres exemples similaires sont adaptables bien entendu.

D'autres possibilités sont offertes et Google a même mis en place une petite API Javascript pour contrôler les Feature-Policy. Je ne vais pas tout vous détailler ici car ce ne sont encore que les prémices du système, mais c'est très intéressant. Ce ne sont que quelques nouvelles fonctions (compatibles dans Google Chrome au moins) qui permettent de jouer avec les permissions, comme dans l'exemple suivant :

document.policy.allowsFeature('geolocation');
document.policy.allowsFeature('geolocation', 'https://google-developers.appspot.com/');

Si une fonctionnalité est bloquée (comme la géolocalisation ici), voici le type de message que l'on peut recevoir à l'écran.

Blocage de la gélolocalisation avec l'entête HTTP Feature-Policy

Si vous souhaitez connaître la liste des fonctionnalités et API disponibles, et surtout tester le fonctionnement des Feature Policy, rendez-vous sur les sites Chrome's source, ChromeStatus ou https://feature-policy-demos.appspot.com. Vous pouvez également aller sur le classique Caniuse pour vérifier la compatibilité du système, pour le moment limiter à Chrome et Safari à l'heure d'écrire ces lignes.