Show Menu
SUJETS×

Stratégie de sécurité du contenu (CSP)

L’objectif principal d’une stratégie de sécurité du contenu (CSP) est d’éviter les attaques par l’exécution de scripts de site à site (XSS). Elles se produisent lorsque le navigateur est amené à exécuter du contenu malveillant qui semble provenir d’une source de confiance, mais qui vient en réalité d’ailleurs. La stratégie de sécurité du contenu permet au navigateur (au nom de l’utilisateur) de vérifier que le script provient bien d’une source de confiance.
Une stratégie de sécurité du contenu (CSP) est mise en œuvre en ajoutant l’en-tête HTTP Content-Security-Policy aux réponses de votre serveur. Vous pouvez en apprendre davantage sur la stratégie de sécurité du contenu sur le site Mozilla Developer Network : https://developer.mozilla.org/fr-FR/docs/Web/HTTP/CSP

Problèmes à résoudre

Les systèmes de gestion des balises sont développés pour charger les scripts de façon dynamique. La stratégie de sécurité du contenu est conçue pour bloquer ces scripts chargés dynamiquement, car ils peuvent occasionner des problèmes de sécurité.
Si vous souhaitez que Launch soit conforme à votre stratégie de sécurité du contenu, deux critères principaux doivent être remplis :
  • La source de votre bibliothèque Launch doit être fiable. Si cette condition n’est pas remplie, la bibliothèque Launch et les autres fichiers JavaScript requis sont bloqués par le navigateur et ne se chargent pas sur la page.
  • Les scripts intégrés doivent être autorisés. Si cette condition n’est pas remplie, les actions des règles Custom Code (Code personnalisé) sont bloquées sur la page et ne s’exécuteront pas correctement.
Si vous souhaitez utiliser Launch et avoir une stratégie de sécurité du contenu mise en place, vous devez corriger ces deux problèmes sans que les autres scripts soient considérés comme sûrs par erreur. Augmenter la sécurité revient à augmenter votre charge de travail.

Sources de confiance

Si vous auto-hébergez votre bibliothèque, alors la source de votre bibliothèque est probablement votre propre domaine. Vous pouvez spécifier que le domaine hôte est une source sûre comme celle-ci :
script-src 'self'
Si c’est Adobe qui héberge la bibliothèque (avec l’hôte géré par Adobe), alors votre bibliothèque est gérée sur assets.adobedtm.com. Dans ce cas, veillez à ce que votre stratégie de sécurité ressemble à celle-ci :
script-src 'self' assets.adobedtm.com
Vous devez spécifier self comme domaine de sécurité pour ne pas interrompre les scripts qui sont déjà en cours de chargement, mais il est également nécessaire de faire reconnaître assets.adobedtm.com comme sûr ou votre bibliothèque Launch ne se chargera pas sur cette page.
Vous pouvez en apprendre davantage sur les sources de confiance sur le site Mozilla Developer Network .

Scripts intégrés

Les scripts intégrés représentent un défi pour la stratégie de sécurité du contenu, car ils sont interdits par défaut. Vous disposez de deux options pour autoriser les scripts intégrés :
  • Autoriser tous les scripts intégrés (la moins sûre)
  • Autoriser par valeur à usage unique (bon niveau de sécurité)
La spécification CSP contient des détails sur une troisième option utilisant des hachages, mais cette approche n’est pas réalisable avec un système de gestion des balises (TMS) de quelque type que ce soit, pour un certain nombre de raisons, dont certaines très compliquées.

Bon niveau de sécurité - Valeurs à usage unique

Cette méthode implique de générer une valeur à usage unique et de l’ajouter à votre CSP et à chaque script intégré. Lorsque le navigateur reçoit une instruction de chargement d’un script intégré avec une valeur à usage unique dessus, comparez celle-ci à ce qui est contenu dans l’en-tête de la CSP. Si cela concorde, le script est chargé.
Cette valeur à usage unique doit être modifiée à chaque nouveau chargement de page.
Il y a une condition préalable très importante : vous devez charger la bibliothèque Launch de manière asynchrone . Cela ne fonctionne pas avec un chargement synchrone de la bibliothèque Launch (entraîne des erreurs de console et des règles dont l’exécution ne se fait pas correctement).
Vous pouvez ajouter votre valeur à usage unique à l’exemple de CSP hébergée par Adobe ci-dessus comme ceci :
script-src 'self' assets.adobedtm.com 'nonce-2726c7f26c'
Vous devez alors indiquer à Launch où trouver la valeur à usage unique. Launch l’utilise lors du chargement d’un script intégré. Pour que Launch utilise la valeur à usage unique lors du chargement du script, vous devez :
  1. créer un élément de données qui référence votre valeur à usage unique (où que vous l’ayez placée dans la couche de données) ;
  2. configurer l’extension Core et spécifier l’élément de données que vous avez utilisé ;
  3. publier les modifications apportées à l’élément de données et à l’extension Core.
Remarque supplémentaire : seul le chargement de votre code personnalisé (Custom Code) est pris en charge. Il ne gère pas ce que vous faites dans votre code personnalisé. Vous pouvez écrire un code personnalisé qui n’est pas conforme à votre CSP, auquel cas la CSP a priorité. Par exemple, si vous utilisez un code personnalisé pour charger un script intégré en l’ajoutant au DOM, Launch ne peut pas le trouver ni ajouter correctement la valeur à usage unique. Ainsi, cette action Custom Code particulière ne fonctionnera pas comme prévu.

Faible niveau de sécurité - Autoriser l’intégration

Si l’option ci-dessus ne fonctionne pas pour vous, vous pouvez indiquer à votre CSP d’autoriser tous les scripts intégrés. Il s’agit de l’option la moins sécurisée, mais elle est également plus facile à mettre en œuvre et à gérer.
Encore une fois, en supposant qu’Adobe gère l’hébergement et que vous identifiiez le domaine assets.adobedtm.com comme source de confiance, votre CSP ressemblerait à ceci :
script-src 'self' assets.adobedtm.com 'unsafe-inline'
Pour plus d’informations sur l’autorisation des scripts intégrés, voir https://developer.mozilla.org/fr-FR/docs/Web/HTTP/Headers/Content-Security-Policy/script-src sur le site de MDN.