Conçue pour contrôler et limiter les ressources pouvant être téléchargées sur une page, la fonctionnalité dite de "politique de sécurité du contenu", bien que compatible avec l'écrasante majorité des navigateurs actuellement utilisés, demeure peu employée. Pourtant, parallèlement à la formalisation par le World Wide Web Consortium d'une première version de cette fonctionnalité de sécurité, puis à la présentation d'une version deux en 2016, l'usage des outils de gestion des balises n'a cessé de progresser et avec lui le risque de fuites de données. Dès lors, comment expliquer qu'à date, le paramétrage d'une politique de sécurité du contenu n'aille pas de soi lors de l'installation d'un outil de gestion des balises ?
La politique de sécurité du contenu
La politique de sécurité du contenu s'applique au niveau d'un document HTML. Elle peut être spécifiée via une balise HTML meta, au sein du code source d'une page, ou sous la forme d'une propriété de l'en-tête HTTP retourné par le serveur en réponse à une demande d'accès à une page Web. A noter : il est impossible d'ajouter dynamiquement la balise HTML meta, de la politique de sécurité du contenu, via des codes JavaScript, comme cela est possible pour les balises HTML utiles au référencement naturel, telle que la meta canonical par exemple.
La politique de sécurité du contenu permet de définir, sous forme d'une liste blanche, les types de ressources dont le chargement est autorisé sur une page, ainsi que leur origine. Le niveau de granularité disponible, en terme de filtrage, atteint même la méthode de chargement utilisée pour ajouter une ressource.
La politique de sécurité du contenu permet donc de s'assurer qu'un code externe ne puisse pas faire office de cheval de Troie afin de télécharger de nouvelles ressources, sous la forme de codes de second ou de troisième niveau. De même, il est possible d'imaginer autoriser le téléchargement d'un code JavaScript, depuis un domaine donné, mais d'interdire toute transmission d'informations à destination du même domaine, sous forme d'image, d'iframe, ou de requête XHR. A l'inverse, les responsables de la sécurité pourront estimer que limiter les types de ressources autorisés pour un domaine de collecte donné, aux images et iframe, suffira à garantir la maîtrise des données transmises, la construction des URLs de collecte s'effectuant alors nécessairement dans l'outil de gestion des balises.
Aux origines du mal : le paramétrage côté serveur de la politique de sécurité du contenu
Impossible à définir côté client, le paramétrage d'une politique de sécurité du contenu, rend incontournable la participation des équipes techniques en charge de la maintenance d'un site Web. Elles sont d'ailleurs, le plus souvent, porteuse du projet de déploiement initial de cette fonctionnalité. En effet, sensibles aux risques de sécurité que présente l'utilisation d'un outil de gestion des balises et plus généralement l'inclusion de codes JavaScript externes pouvant être mis à jour sans validation préalable, les équipes techniques voient, à raison, dans la politique de sécurité du contenu, un moyen simple et efficace de maintenir leur contrôle sur le site Web. En outre, n'étant en rien impactées dans leur processus métier par la mise en œuvre de la politique de sécurité du contenu, elles ne voient dans son introduction que des avantages.
A l'inverse, les équipes marketing et plus généralement les utilisateurs de l'outil de gestion des balises sont les premiers concernés par son utilisation. La politique de sécurité du contenu, fonctionnant sous forme de liste blanche, leur impose de déposer une demande, auprès des équipes techniques, à chaque ajout d'une balise correspondant à un nouveau partenaire. Ce faisant, le principe même de la gestion des balises, à savoir la possibilité d'ajouter rapidement et de façon autonome, au moyen d'une interface utilisateur simplifiée, des codes sur un dispositif, se voit remise en question. En effet, le déploiement de nouveaux codes redevient tributaire du paramétrage d'éléments externes à l'outil de gestion des balises.
En conclusion
L'allongement des cycles de déploiement, conjugué à un manque de visibilité sur le fonctionnement technique de la politique de sécurité du contenu, explique la réticence des équipes recourant aux outils de gestion des balises, à la voir implantée. Le plus souvent, les gains obtenus en terme de sécurité apparaissent insuffisants, pour les utilisateurs de l'outil de gestion des balises, au regard du préjudice induit par la perte d'agilité qui accompagne l'utilisation d'une politique de sécurité du contenu.
Pourtant, les menaces liées à l'appel de ressources externes, sur la confidentialité des données, notamment à l'ère du Règlement Général sur la Protection des Données, sont bien réelles. Les contraintes que font peser le maintien d'une politique de sécurité du contenu doivent être envisagées positivement. D'une part parce qu'elles concernent principalement l'ajout de codes de nouveaux partenaires et non la mise à jour de ceux existants. D'autre part, parce qu'elle a le mérite de rendre incontournable la traçabilité des processus de transfert des données, du site Web vers les partenaires, pour les utilisateurs d'outils de gestion des balises, contribuant par là même à les responsabiliser davantage concernant cette problématique.