Les chercheurs découvrent des fuites de données dans Google Tag Manager (GTM), ainsi que des vulnérabilités de sécurité, des injections de scripts arbitraires et des instances de consentement pour la collecte de données activées par défaut. Une analyse juridique identifie les violations potentielles de la législation européenne sur la protection des données.
Il existe de nombreuses révélations troublantes, notamment que le GTM côté serveur « entrave les efforts d'audit de conformité des régulateurs, des responsables de la protection des données et des chercheurs… »
Concernant la vulnérabilité, les chercheurs ont écrit :
« Cette découverte montre que le système d'autorisation GTM implémenté dans le bac à sable Web Container permet aux balises d'insérer des scripts arbitraires et incontrôlés, ouvrant ainsi la voie à des vulnérabilités potentielles en matière de sécurité et de confidentialité du site Web.
Nous avons divulgué cette découverte à Google via leur système en ligne Bug Bounty.
GTM, développé par Google en 2012 pour aider les éditeurs à mettre en œuvre des scripts JavaScript tiers, est actuellement utilisé sur 28 millions de sites Web. L'étude de recherche évalue les deux versions de GTM, côté client et le nouveau GTM côté serveur introduit en 2020.
L'analyse, entreprise par des chercheurs et des experts juridiques, a révélé un certain nombre de problèmes inhérents à l'architecture du GTM.
Un examen de 78 balises côté client, 8 balises côté serveur et deux plates-formes de gestion du consentement (CMP) a révélé des fuites de données cachées, des instances de balises contournant les systèmes d'autorisation GTM afin d'injecter des scripts et un consentement activé par défaut sans toute interaction de l'utilisateur.
Une découverte importante concerne le GTM côté serveur. Le GTM côté serveur fonctionne en chargeant et en exécutant des balises sur un serveur distant, ce qui crée la perception de l'absence de tiers sur le site Web. Cependant, l'étude a montré que cette architecture permet aux balises exécutées sur le serveur de partager clandestinement les données des utilisateurs avec des tiers, contournant les restrictions du navigateur et les mesures de sécurité telles que la Content-Security-Policy (CSP).
Méthodologie utilisée dans la recherche sur les fuites de données GTM
Les chercheurs proviennent du Centre Inria de l'Université, du Centre Inria d'Université Côte d'Azur, du Centre Inria de l'Université et de l'Université d'Utrecht.
La méthodologie utilisée par les chercheurs consistait à acheter un domaine et à installer GTM sur un site Web en direct.
Le document de recherche explique en détail :
« Pour mener des expériences et mettre en place l'infrastructure GTM, nous avons acheté un domaine – nous l'appelons ici exemple.com – et avons créé un site Web public contenant une page Web de base avec un paragraphe de texte et un formulaire de connexion HTML. Nous avons inclus un formulaire de connexion depuis Senol et al. … Nous avons récemment découvert que les saisies des utilisateurs sont souvent divulguées à partir des formulaires. Nous avons donc décidé de tester si les balises pouvaient être responsables de telles fuites.
Le site Web et l'infrastructure GTM côté serveur étaient hébergés sur une machine virtuelle que nous avons louée sur la plateforme de cloud computing Microsoft Azure située dans un centre de données dans l'UE.
…Nous avons utilisé la fonctionnalité « profils » du navigateur pour démarrer chaque expérience dans un nouvel environnement, dépourvu de cookies, de stockage local et d'autres technologies que celles de maintien d'un état.
Le navigateur visitant le site Web était exécuté sur un ordinateur connecté à Internet via un réseau institutionnel de l’UE.
Pour créer des installations GTM côté client et serveur, nous avons créé un nouveau compte Google, nous y sommes connectés et avons suivi les étapes suggérées dans la documentation officielle de GTM.
Les résultats de l'analyse contiennent plusieurs conclusions critiques, notamment le fait que la « balise Google » facilite la collecte de plusieurs types de données d'utilisateurs sans consentement et qu'au moment de l'analyse, elle présentait une faille de sécurité.
La collecte de données est cachée aux éditeurs
Une autre découverte a été l'étendue de la collecte de données par le « Pinterest Tag », qui a permis de recueillir une quantité importante de données utilisateur sans les divulguer à l'éditeur.
Ce que certains peuvent trouver inquiétant, c'est que les éditeurs qui déploient ces balises non seulement ignorent les fuites de données, mais que les outils sur lesquels ils s'appuient pour les aider à surveiller la collecte de données ne les informent pas de ces problèmes.
Les chercheurs ont documenté leurs découvertes :
« Nous constatons que les données envoyées par la balise Pinterest ne sont pas visibles par l'éditeur sur le site Pinterest, où nous nous sommes connectés pour observer la divulgation par Pinterest des données collectées.
De plus, nous constatons que les données collectées par le Google Tag concernant l'interaction avec le formulaire ne sont pas affichées dans le tableau de bord Google Analytics.
Cette découverte démontre que pour de telles balises, les éditeurs ne sont pas conscients des données collectées par les balises qu'ils sélectionnent.
Injections de scripts tiers
Google Tag Managers dispose d'une fonctionnalité permettant de contrôler les balises, y compris les balises tierces, appelées conteneurs Web. Les balises peuvent s'exécuter dans un bac à sable, ce qui limite leurs fonctionnalités. Le bac à sable utilise également un système d'autorisations avec une autorisation appelée inject_script qui permet à un script de télécharger et d'exécuter n'importe quel script (arbitraire) en dehors du conteneur Web.
L'autorisation inject_script permet à la balise de contourner le système d'autorisation GTM pour accéder à toutes les API du navigateur et au DOM.
Capture d'écran illustrant l'injection de script
Les chercheurs ont analysé 78 balises côté client officiellement prises en charge et ont découvert 11 balises qui ne disposent pas de l'autorisation inject_script mais peuvent injecter des scripts arbitraires. Sept de ces onze balises ont été fournies par Google.
Ils écrivent:
« 11 des 78 balises officielles côté client injectent un script tiers dans le DOM en contournant le système d'autorisation GTM ; et le « Mode Consentement » de GTM active certaines finalités de consentement par défaut, avant même que l'utilisateur n'ait interagi avec la bannière de consentement.
La situation est encore pire car il ne s’agit pas seulement d’une vulnérabilité en matière de confidentialité, mais également d’une vulnérabilité en matière de sécurité.
Le document de recherche explique la signification de ce qu’ils ont découvert :
« Cette découverte montre que le système d'autorisation GTM implémenté dans le bac à sable Web Container permet aux balises d'insérer des scripts arbitraires et incontrôlés, ouvrant ainsi la voie à des vulnérabilités potentielles en matière de sécurité et de confidentialité du site Web. Nous avons divulgué cette découverte à Google via leur système en ligne Bug Bounty.
Plateformes de gestion du consentement (CMP)
Les plateformes de gestion du consentement (CMP) sont une technologie permettant de gérer le consentement que les utilisateurs ont accordé en termes de confidentialité. Il s'agit d'un moyen de gérer la personnalisation des annonces, le stockage des données utilisateur, le stockage des données analytiques, etc.
La documentation de Google pour l'utilisation du CMP indique que la définition des paramètres par défaut du mode de consentement relève de la responsabilité des spécialistes du marketing et des éditeurs qui utilisent le GTM.
Les valeurs par défaut peuvent être définies pour refuser la personnalisation des annonces par défaut, par exemple.
La documentation indique :
" Définir les paramètres de consentement par défaut Nous vous recommandons de définir une valeur par défaut pour chaque type de consentement que vous utilisez.
Les valeurs de l’état de consentement présentées dans cet article ne sont que des exemples. Vous êtes responsable de vous assurer que le mode de consentement par défaut est défini pour chacun de vos produits de mesure afin de correspondre à la politique de votre organisation.
Ce que les chercheurs ont découvert, c'est que les CMP pour les GTM côté client sont chargés dans un état indéfini sur la page Web, ce qui devient problématique lorsqu'un CMP ne charge pas les variables par défaut (appelées variables non définies).
Le problème est que GTM considère les variables non définies comme signifiant que les utilisateurs ont donné leur consentement à toutes les variables non définies, même si l'utilisateur n'a donné son consentement d'aucune manière.
Les chercheurs ont expliqué ce qui se passe :
« Étonnamment, dans ce cas, GTM considère que toutes ces variables non définies sont acceptées par l'utilisateur final, même si l'utilisateur final n'a pas encore interagi avec la bannière de consentement de la CMP.
Parmi deux CMP testées (voir §3.1.1), nous avons détecté ce comportement pour la CMP Consentmanager.
Cette CMP définit une valeur par défaut à seulement deux variables de consentement – Analytics_storage et ad_storage – laissant trois variables de consentement GTM – security_-storage, personalization_storage feature_storage – et des variables de consentement spécifiques à cette CMP – par exemple, cmp_Purpose_c56 qui correspond à l'objectif « Médias Sociaux » – dans un état indéfini.
Ces variables supplémentaires sont donc considérées comme accordées par GTM. En conséquence, toutes les balises qui dépendent de ces quatre variables de consentement sont exécutées même sans le consentement de l'utilisateur.
Implications légales
Le document de recherche note que les lois américaines sur la protection de la vie privée, comme le Règlement général sur la protection des données (RGPD) de l'Union européenne et la Directive ePrivacy (ePD), réglementent le traitement des données des utilisateurs et l'utilisation de technologies de suivi et imposent des amendes importantes en cas de violation de ces lois, comme comme exigeant le consentement pour le stockage de cookies et d'autres technologies de suivi.
Une analyse juridique du Client-Side GTM a signalé un total de sept violations potentielles.
Sept violations potentielles des lois sur la protection des données
Violation potentielle 1. Les scanners CMP manquent souvent leurs objectifs
Violation potentielle 2 . Le mappage des objectifs CMP aux variables de consentement GTM n'est pas conforme.
Violation potentielle 3. Les objectifs GTM sont limités au stockage côté client.
Violation potentielle 4. Les objectifs de GTM ne sont ni spécifiques ni explicites.
Violation potentielle 5. Le fait de définir par défaut les variables de consentement sur « accepté » signifie que les balises s'exécutent sans consentement.
Violation potentielle 6. Google Tag envoie des données indépendamment des décisions de consentement de l'utilisateur.
Violation potentielle 7. GTM permet aux fournisseurs de balises d'injecter des scripts exposant les utilisateurs finaux à des risques de sécurité.
Analyse juridique de Server-Side GTM
Les chercheurs écrivent que les résultats soulèvent des préoccupations juridiques concernant GTM dans son état actuel. Ils affirment que le système introduit plus de contestations juridiques que de résolutions, ce qui complique les efforts de conformité et pose un défi aux régulateurs pour qu'ils puissent effectuer une surveillance efficace.
Voici quelques-uns des facteurs qui ont suscité des inquiétudes quant à la capacité de se conformer à la réglementation :
Le respect des droits des personnes concernées est difficile pour l'éditeur Tant pour le GTM côté client que côté serveur, il n'existe pas de moyen simple pour un éditeur de se conformer à une demande d'accès aux données collectées, comme l'exige l'article 15 du RGPD. L'éditeur devrait retrouver manuellement chaque collecteur de données pour se conformer à cette demande légale.
Le consentement intégré soulève des problèmes de confiance Lorsqu'ils utilisent des balises avec consentement intégré, les éditeurs sont obligés de croire que les fournisseurs de balises implémentent réellement le consentement intégré dans le code. Il n'existe pas de moyen simple pour un éditeur d'examiner le code afin de vérifier que le fournisseur de balises ignore réellement le consentement et collecte les informations de l'utilisateur. La révision du code est impossible pour les balises officielles qui sont placées en bac à sable dans le script gtm.js. Les chercheurs affirment que la vérification de la conformité du code « nécessite une ingénierie inverse importante ».
Le GTM côté serveur est invisible pour la surveillance et l'audit réglementaires Les chercheurs écrivent que les blocages GTM côté serveur entravent l'audit de conformité car la collecte de données s'effectue à distance sur un serveur.
Le consentement est difficile à configurer sur les conteneurs du serveur GTM Les outils de gestion du consentement sont absents dans les conteneurs du serveur GTM, ce qui empêche les CMP d'afficher les finalités et les collecteurs de données comme l'exige la réglementation.
L’audit est décrit comme très difficile :
« De plus, l'audit et la surveillance sont exclusivement réalisables en contactant uniquement l'éditeur pour accorder l'accès à la configuration du conteneur de serveur GTM.
De plus, l'Editeur est en mesure de modifier la configuration du Conteneur du Serveur GTM à tout moment (par exemple avant toute enquête réglementaire), masquant ainsi tout contrôle de conformité.
Conclusion : GTM présente des pièges et des défauts
Les chercheurs ont attribué à GTM de mauvaises notes en matière de sécurité et de défauts de conformité, affirmant qu'il introduit plus de problèmes juridiques que de solutions, tout en compliquant la conformité aux réglementations et en rendant difficile le contrôle de la conformité par les régulateurs.