Le CSP strict n'autorise pas l'évaluation non sécurisée
Table des matières
Qu'est-ce que cela signifie ?
La Content Security Policy (CSP) est une politique de sécurité qui indique aux navigateurs quels types de code sont autorisés à s'exécuter sur une page web. La directive « unsafe-eval » contrôle spécifiquement si le JavaScript peut être généré et exécuté de manière dynamique lors de l'exécution, par exemple via la fonction eval() ou le constructeur Function(). Une CSP stricte, qui n’autorise pas « unsafe-eval », bloque précisément ce type d’exécution dynamique de code dans le navigateur. Cela concerne non seulement le code propre au site web, mais aussi les outils externes qui chargent et exécutent du contenu à l’exécution, comme c’est le cas avec les outils de tests A/B côté client.
La création et la livraison fonctionnent-elles également sans « unsafe-eval » ?
Non, d'un point de vue technique, la création et la mise en place d'expériences ne sont pas possibles sans `unsafe-eval`. Cela s'explique par le fonctionnement même du snippet : les expériences ne sont pas intégrées de manière statique lors du déploiement de la page, mais récupérées par le snippet en tant que configuration lors de l'exécution, puis appliquées dans le navigateur par un moteur JavaScript. C'est précisément ce qui permet de créer ou de modifier une expérience dans le tableau de bord sans qu'un nouveau déploiement soit nécessaire du côté du client.
Une CSP ne peut toutefois autoriser que le code qu’elle connaît à l’avance, via une source fixe, un hachage ou un nonce. Aucune de ces méthodes ne fonctionne pour les contenus qui ne sont assemblés qu’après le chargement de la page. Pour que le navigateur puisse tout de même exécuter ce code, il faut recourir à eval() ou au constructeur Function(), c’est-à-dire précisément ce que contrôle unsafe-eval. Comme la logique de ciblage et les modifications de contenu passent par le même moteur, il n’existe pas de chemin d’exécution distinct et “ sécurisé ” que l’on pourrait activer uniquement pour de simples expériences (texte, CSS, images).
Solution possible
Au lieu d'autoriser « unsafe-eval » à l'échelle du site, le CSP peut être configuré différemment pour chaque route. Les pages soumises à des exigences particulièrement strictes (par exemple, les flux de connexion ou d'authentification) restent strictement protégées et exemptes d'« eval », tandis que « unsafe-eval » n'est autorisé que sur les pages où des expériences doivent effectivement être menées.