Comment les scripts tiers arrivent sur un site web
Lors du développement d'un site web, vous inclurez souvent des bibliothèques pour accélérer le processus de développement et éviter de réinventer la roue. Cependant, il arrive parfois que vous deviez charger un script depuis une source externe. En raison d'attaques récentes telles que la prise de contrôle du domaine Polyfill, des questions ont été soulevées : pourquoi avez-vous même besoin de scripts tiers ? Comment se retrouvent-ils sur un site web ?
Tout d'abord, plantons le décor. Les scripts tiers sont des fichiers JavaScript servis depuis un serveur autre que le vôtre. Par exemple, supposons que je gère mon site web, cside.com. Ce site web a été créé par une équipe de développeurs, qui ont utilisé un certain nombre de bibliothèques pour le construire. Cela est ensuite compilé / transformé / divisé en fichiers JavaScript plus petits et moins nombreux que le code source d'origine. C'est ce que nous appelons le JavaScript de première partie – il est servi en tant que ressource à l'intérieur de cside.com, par exemple cside.com/_next/static/chunks/main-ab76c1828cff9b09.js.
Une semaine plus tard, un membre de l'équipe marketing demande aux développeurs d'ajouter un script au site pour leur produit d'analyse de choix. Maintenant, le site a son premier JavaScript tiers. Ce processus peut se poursuivre avec l'équipe juridique demandant une bannière de cookies, le marketing demandant un autre script d'analyse, et ainsi de suite.
Les développeurs connaissent les risques du JavaScript tiers, alors ils recherchent l'outil en ligne, font quelques recherches et le jugent digne de confiance.
Ce cycle se répète jusqu'à ce qu'il y ait une douzaine de scripts ou plus sur la page. Tous légitimes, tous importants et tous tiers. Dans le pire des cas, l'un de ces domaines est acheté, du trafic malveillant est servi et votre site devient infecté.
Mais c'est exagéré – et ce n'est pas souvent ainsi que les attaques se produisent réellement. Les scripts de premier niveau sur votre site ne sont généralement pas ceux qui sont ciblés, bien que cela soit possible (voir notre analyse de Polyfill ici). Souvent, les scripts chargent d'autres scripts. Certains scripts peuvent même créer des iframes et charger encore plus de scripts. Tout comme votre code de première partie utilise un certain nombre de dépendances, les scripts tiers ont également des exigences pour se rendre fonctionnels et ont leur propre chaîne d'approvisionnement.
Parfois, même les bibliothèques de première partie que vous ajoutez peuvent charger un script pendant l'exécution. Elles peuvent fournir un composant React pratique à intégrer dans votre page, mais en coulisses, elles ajoutent quelques scripts pour se rendre fonctionnelles. Qu'il s'agisse de charger la localisation, leurs propres analyses, des thèmes ou plus - cela s'ajoute à la chaîne d'approvisionnement tierce de votre site web.
Vous pourriez donc penser : pourquoi ne pas simplement télécharger ces scripts et les héberger vous-même ? Pour certains scripts de base, tels que jQuery, c'est un choix évident - et que nous recommandons. Si vous avez affaire à un script statique dans la chaîne d'approvisionnement de votre site, ramenez-le à votre origine si possible.
Cependant, de nombreux scripts servent du contenu dynamique basé sur le demandeur. Par exemple, ils peuvent examiner votre User Agent dans la requête et décider que vous avez besoin d'une version différente avec des fonctionnalités supplémentaires. Ou, ils peuvent examiner votre IP et décider de vous envoyer une localisation différente du script.
Ceux-ci sont toujours statiques par utilisateur la plupart du temps, mais surtout pas statiques globalement. Cela signifie qu'en servant le script vous-même, vous ne serviriez qu'une seule variation, pas la suite complète de scripts nécessaires pour offrir à vos utilisateurs la meilleure expérience.
Certains scripts peuvent même avoir des URL codées en dur vers des sous-scripts qu'ils chargeront. Cela signifie que même si vous copiez le script racine sur votre site, il chargera toujours des scripts externes depuis une URL distante.
Même les bibliothèques que vous pourriez utiliser tous les jours dans votre application suivent ce modèle. Examinons quelques exemples :
Le package npm Intercom charge tout un tas de scripts à l'exécution :
https://developers.intercom.com/installing-intercom/web/installation#single-page-app
Même lors de l'utilisation d'outils de suivi des médias sociaux, qui sont inévitables pour la plupart des entreprises faisant du marketing sur les médias sociaux, la première chose que font les scripts qu'ils vous donnent est de charger un autre script tiers :
Ou, vous utilisez un package React tel que @monaco-editor/react, avec plus de 712 000 téléchargements hebdomadaires, qui charge un script tiers pour une grande partie de ses fonctionnalités : https://www.npmjs.com/package/@monaco-editor/react
Alors, où allons-nous à partir de là ? C'est pourquoi cside existe. Nous proxyfions chaque script qui se charge dans la page - même ceux chargés pendant l'exécution. Nous réécrivons les URL de script pour passer par notre Proxy cside, qui est capable de bloquer un script avant même qu'il ne soit servi au client.
Notre proxy offre un point de vue unique : permettant une politique par URL, par domaine, par hash, par en-têtes qui peut être déployée globalement en quelques secondes. Si un script tente de charger un script enfant, cside le saura et le proxyfiera. Et vous donnera ensuite le contrôle pour décider de ce qui se passe : autoriser ce script, bloquer ce script, et les analyses qui vont avec.
Pour chaque script que notre proxy voit, nous le transmettons à notre moteur de détection. Notre moteur de détection décompose le script - jusqu'au niveau AST - pour comprendre ce qu'il fait. Et nous faisons cela pour chaque léger changement dans un script, même s'il s'agit d'un caractère. Nous pouvons vous informer de ce qu'un script fait, quand son accès à votre site change, et toute une série d'informations de confiance autour de la source.
Nous avons des analystes de sécurité qui travaillent 24 heures sur 24 pour repérer les menaces émergentes et les bloquer au niveau de notre couche proxy avant qu'elles n'impactent l'un de vos clients. Combinez cela avec le moteur de détection automatique susmentionné, et vous avez maintenant un contrôle total sur la chaîne d'approvisionnement tierce de votre site.
Vous pouvez vous inscrire à notre niveau gratuit ici.
La chaîne d'approvisionnement du navigateur vous intéresse-t-elle ? Si oui, rejoignez-nous dans la mission de protéger chaque utilisateur du World Wide Web : https://cside.com/careers
