Scripts tiers sur votre site : chaque tag est un risque

Ouvrez votre site web maintenant et comptez combien de services externes il charge. Google Analytics. Google Tag Manager. Facebook Pixel. Un widget de chat en direct. Google Fonts. jQuery depuis un CDN. Une banniere de consentement aux cookies. Un embed YouTube. Un flux Twitter. Un widget d'avis clients. Un outil de heatmap comme Hotjar.

Le site professionnel moyen charge entre 15 et 30 scripts tiers. Certains sites e-commerce en chargent 40 ou plus. Chacun de ces scripts s'execute avec un acces complet a votre page web. Ils peuvent lire les saisies de formulaires. Ils peuvent modifier la page. Ils peuvent intercepter les clics. Ils peuvent rediriger les visiteurs. Ils peuvent voler des donnees.

Si l'un de ces services tiers est compromis, vos visiteurs sont affectes. Non pas parce que vous avez fait quelque chose de mal, mais parce que vous avez fait confiance au code de quelqu'un d'autre pour s'executer sur vos pages.

C'est le risque de supply chain applique au web, et c'est l'une des menaces de securite les plus sous-estimees auxquelles les entreprises font face aujourd'hui.

Ce que les scripts tiers peuvent faire sur votre page

Quand vous ajoutez un script tiers a votre site web (un tag <script> pointant vers un domaine externe), ce script s'execute avec les memes permissions que votre propre code. Il n'y a pas de sandbox, pas de restriction, pas de frontiere. Il a un acces complet a :

• L'ensemble du DOM : Il peut lire et modifier chaque element de la page.
• Les donnees de formulaires : Il peut lire tout ce qu'un utilisateur tape dans les formulaires, y compris les mots de passe et les numeros de carte de credit.
• Les cookies : Il peut lire les cookies non marques comme HttpOnly.
• Le stockage local et de session : Il peut lire et ecrire dans le stockage local du navigateur.
• Les requetes reseau : Il peut faire des requetes HTTP vers n'importe quel domaine.
• Les interactions utilisateur : Il peut suivre les clics, les defilements, les mouvements de souris et les frappes clavier.

Le probleme de la supply chain

Les attaques de supply chain sur les sites web fonctionnent ainsi : au lieu d'attaquer votre site directement, un attaquant compromet l'un des services tiers dont votre site depend. Quand le service compromis delivre son script modifie a vos visiteurs, le code malveillant s'execute sur vos pages comme si vous l'aviez mis vous-meme.

Pour un examen plus approfondi du fonctionnement des attaques de supply chain dans le contexte des plugins CMS, consultez notre article sur les attaques de supply chain via les plugins.

Pourquoi les attaques de supply chain sont efficaces

• Echelle : Compromettre une bibliotheque ou un service tiers populaire peut affecter des milliers ou des millions de sites web simultanement.
• Confiance : Les proprietaires de sites font confiance a leurs fournisseurs tiers. Les scripts se chargent automatiquement a chaque vue de page.
• Discretion : La modification malveillante peut etre subtile, n'ajoutant que quelques lignes de code qui ne s'activent que sur les pages de paiement.
• Persistance : Tant que votre site charge le script compromis, l'attaque continue.

Le cas British Airways : une lecon a 230 millions de dollars

La violation de donnees de British Airways en 2018 est l'un des exemples les plus instructifs d'une attaque par script tiers. Les attaquants ont injecte un script malveillant de seulement 22 lignes de JavaScript qui ciblait specifiquement la page de paiement de la compagnie aerienne.

L'attaque a dure environ 15 jours avant d'etre detectee. Pendant cette periode, environ 380 000 details de cartes de paiement ont ete voles. L'ICO du Royaume-Uni a impose une amende de 20 millions de livres sterling sous le GDPR.

Pour en savoir plus sur les attaques de pages de paiement, consultez notre article sur le web skimming dans l'e-commerce.

Scripts tiers courants sur les sites professionnels

Analytics et suivi

• Google Analytics / GA4 : Charge sur presque chaque site professionnel. Suit les pages vues, le comportement utilisateur, les conversions.
• Google Tag Manager : Particulierement puissant. GTM est essentiellement une plateforme pour charger et gerer d'autres scripts. Quiconque a acces a votre conteneur GTM peut deployer du JavaScript arbitraire sur votre site.
• Facebook/Meta Pixel : Suit le comportement utilisateur a des fins publicitaires.
• Hotjar, Crazy Egg, FullStory : Outils d'enregistrement de sessions et de heatmap.

Fonctionnalite

• Widgets de chat en direct : Intercom, Drift, Zendesk Chat. Chargent du JavaScript significatif.
• Widgets d'avis clients : Trustpilot, Google Reviews. Chargent du contenu externe sur votre page.
• Embeds de medias sociaux : Flux Twitter/X, galeries Instagram, lecteurs YouTube.

Infrastructure

• Bibliotheques hebergees sur CDN : jQuery, Bootstrap charges depuis des CDN publics.
• Polices web : Google Fonts, Adobe Fonts chargent des fichiers de polices depuis des serveurs externes.
• Plateformes de consentement aux cookies : CookieBot, OneTrust, CookieYes.

Comment auditer les scripts tiers sur votre site

Methode 1 : Outils de developpement du navigateur

1. Ouvrez votre site dans Chrome ou Firefox.
2. Ouvrez les Outils de developpement (F12).
3. Allez a l'onglet Network.
4. Rechargez la page.
5. Filtrez par "JS" pour voir les fichiers JavaScript.
6. Regardez la colonne "Domain". Tout domaine qui n'est pas le votre est un script tiers.
7. Repetez pour les pages cles : page d'accueil, page de contact, pages produits, page de paiement.

Methode 2 : Content Security Policy Report-Only

L'approche la plus complete est de deployer une Content Security Policy en mode report-only. Cela indique aux navigateurs de signaler (mais pas de bloquer) chaque ressource chargee sur votre page qui provient d'un domaine non dans votre liste approuvee.

Subresource Integrity (SRI)

La Subresource Integrity est une fonctionnalite de securite du navigateur qui vous permet de verifier que les scripts charges depuis des sources externes n'ont pas ete modifies. Elle fonctionne en incluant un hash cryptographique du contenu attendu du fichier dans le tag script.

<script src="https://cdn.example.com/library.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8w"
  crossorigin="anonymous"></script>

Limitations de SRI

• Ne fonctionne que pour les fichiers statiques. Si le script tiers change frequemment, le hash ne correspondra plus apres chaque mise a jour.
• Ne fonctionne pas avec les scripts generes dynamiquement.
• Necessite des mises a jour manuelles.

Content Security Policy (CSP)

Une Content Security Policy est un en-tete HTTP qui indique au navigateur quelles sources sont autorisees a charger des ressources sur votre page. C'est la defense la plus puissante contre les attaques par scripts tiers.

Ce que CSP controle

• script-src : Quels domaines peuvent fournir du JavaScript.
• style-src : Quels domaines peuvent fournir du CSS.
• img-src : Quels domaines peuvent fournir des images.
• font-src : Quels domaines peuvent fournir des polices.
• connect-src : Quels domaines peuvent recevoir des requetes AJAX/fetch.
• frame-src : Quels domaines peuvent etre integres dans des iframes.

Defis de CSP

• Scripts inline : De nombreux services tiers necessitent des scripts inline. CSP les bloque par defaut.
• Chaines de tiers : Google Tag Manager charge d'autres scripts, qui peuvent charger encore d'autres scripts.
• Casse de fonctionnalites : Une CSP trop restrictive cassera votre site.

Auto-hebergement des ressources critiques

• Polices : Au lieu de charger Google Fonts depuis fonts.googleapis.com, telechargez les fichiers de polices et servez-les depuis votre propre domaine.
• Bibliotheques JavaScript : Incluez-les dans votre processus de build au lieu de les charger depuis des CDN publics.
• Frameworks CSS : Meme chose que les bibliotheques JavaScript. Auto-hebergez-les.

Impact sur les performances des scripts tiers

• Lookups DNS : Chaque domaine externe necessite un lookup DNS separe.
• Overhead de connexion : Chaque domaine externe necessite un handshake TLS et une connexion HTTP separes.
• Blocage du rendu : Les scripts dans le <head> bloquent le rendu de la page.
• Blocage du thread principal : L'execution JavaScript se fait sur le thread principal du navigateur.
• Decalages de mise en page : Le contenu tiers qui charge apres le rendu initial peut causer des decalages de mise en page.

Implications sur la vie privee sous le RGPD

• Consentement : Sous le RGPD, vous avez besoin du consentement eclaire avant de charger des scripts de suivi.
• Accords de traitement des donnees : Vous avez besoin d'un DPA avec chaque tiers dont le script traite des donnees personnelles.
• Politique de confidentialite : Votre politique de confidentialite doit lister chaque service tiers qui collecte des donnees via votre site.
• Transferts transfrontaliers : Si un script tiers envoie des donnees a des serveurs hors UE/EEE, vous avez besoin de garanties appropriees.

Un plan d'action pratique

1. Audit et inventaire : Creez une liste complete de chaque script tiers sur votre site web.
2. Supprimez ce dont vous n'avez pas besoin : Moins de scripts signifie moins de risques, meilleures performances et conformite plus simple.
3. Auto-hebergez quand c'est possible : Deplacez polices, bibliotheques JavaScript, frameworks CSS sur votre propre hebergement.
4. Implementez SRI pour les ressources statiques.
5. Deployez une Content Security Policy.
6. Utilisez Tag Manager avec precaution : Restreignez l'acces au conteneur GTM. Activez l'authentification a deux facteurs.
7. Surveillez : Configurez la surveillance pour detecter les changements dans les scripts tiers charges sur votre site.

Prochaines etapes

Si vous etes preoccupe par les scripts tiers sur votre site web (et apres avoir lu cet article, vous devriez l'etre), nous pouvons vous aider. Chez Envestis, nous realisons des evaluations de securite de sites web qui incluent un audit approfondi des scripts tiers.

Contactez-nous pour une evaluation. Nous vous donnerons une image claire de votre exposition aux tiers et un plan pratique pour la reduire.