Mises en garde | cside docs

Environnements utilisant un domaine different

Environnement de staging

Afin que cside puisse licencier de maniere precise et securisee notre infrastructure edge, nous utilisons l’en-tete referrer dans les requetes pour determiner si la requete provient d’un client licencie. Cette approche peut comporter certaines mises en garde.

Par exemple, si vous utilisez un environnement de staging, cside ne pourra pas licencier correctement l’infrastructure edge pour les scripts. En effet, l’en-tete referrer sera (souvent) un domaine different. Cela se rencontre frequemment avec les URL de previsualisation/staging qui utilisent un domaine genere dynamiquement, comme Vercel, Netlify et d’autres plateformes.

Environnement local

Nous avons ajoute des mecanismes de detection au script web pour aider avec les environnements locaux, tels que localhost, 127.0.0.1, ::1 et d’autres cas, afin de desactiver automatiquement le script web dans ces environnements. Si vous ne souhaitez pas que cside fonctionne dans l’environnement local, vous pouvez rendre conditionnellement le script web cside.

Iframes cross-origin

Les navigateurs appliquent la politique de meme origine, qui empeche un script s’executant sur votre page principale de lire le contenu d’un iframe charge depuis une autre origine ou d’interagir avec lui. Pour cette raison, le script cside present sur votre page principale ne peut pas voir ni surveiller le DOM a l’interieur d’un iframe cross-origin.

Si vous integrez un iframe qui vous appartient et que vous souhaitez que cside surveille ce qui s’y passe, ajoutez le script cside au document charge dans l’iframe. Le script s’execute alors dans le contexte propre de l’iframe et peut surveiller ce DOM directement, exactement comme il le fait sur votre page principale.

Fonctionne uniquement pour les iframes que vous controlez

Vous ne pouvez ajouter le script cside qu’aux iframes dont vous possedez et pouvez modifier le contenu. cside ne peut pas surveiller les iframes tiers (comme les formulaires de paiement integres, les publicites ou les widgets servis depuis une autre origine), car vous ne pouvez pas injecter de script dans un document que vous ne controlez pas.

Il ne s’agit pas d’une lacune de conformite. Ce qui se passe a l’interieur d’un iframe tiers ne fait pas partie du perimetre PCI DSS de votre boutique, et ne peut pas en faire partie. Vous ne controlez pas le code qui s’execute dans ce document, donc son contenu sort par definition de votre perimetre de conformite. La partie qui sert l’iframe est responsable de ce qui s’y execute.

La menace pertinente est differente : un script malveillant qui injecte un iframe dans votre page. Cette injection se produit dans le contexte de votre propre page, et cside peut la detecter. Surveiller le contenu d’un iframe tiers legitime et detecter l’injection d’un iframe non autorise dans votre page sont deux choses distinctes, et seule la seconde est a la portee de cside.

Scripts en ligne

cside ne surveille actuellement pas les scripts en ligne. Nous prevoyons d’ajouter la prise en charge de la surveillance des scripts en ligne a l’avenir. Nous recommandons d’utiliser l’attribut src pour charger vos scripts, plutot que d’utiliser des scripts en ligne. Mais nous comprenons que cela n’est pas toujours possible.