Si votre plateforme gère 70 marques de casino ou plus, Google Tag Manager fonctionne presque certainement sur tous les domaines. Et dans ces domaines, le nombre d’ID de conteneurs actifs que votre équipe de sécurité a formellement examinés est probablement bien inférieur au nombre réellement exécuté dans les navigateurs des joueurs. Cet écart est le problème fantôme de GTM. Dans Q1 2025, cside a détecté plus de 300 000 signaux d'attaque sur les sites surveillés, l'exécution de scripts non autorisés via des gestionnaires de balises représentant l'un des vecteurs d'attaque les plus cohérents du segment iGaming. En travaillant avec des opérateurs de jeux multimarques, j'ai constaté que l'écart entre les conteneurs que les équipes de sécurité connaissent et les conteneurs réellement exécutés dans les navigateurs des joueurs se creuse à mesure que chaque marque est ajoutée à un portefeuille.
Qu'est-ce qu'un conteneur GTM et pourquoi il est important pour la sécurité
Réponse rapide : Un conteneur Google Tag Manager est un environnement d'exécution JavaScript chargé sur votre domaine avec un accès complet au DOM, aux cookies, au stockage du navigateur et aux requêtes réseau. Toute balise publiée dans ce conteneur s'exécute avec les mêmes autorisations que votre propre code propriétaire. Un ID de conteneur non autorisé sur votre domaine équivaut à accorder à une partie inconnue un accès en écriture à votre interface destinée aux joueurs.**
Google Tag Manager est conçu pour permettre aux non-développeurs de déployer JavaScript sur des sites Web en direct sans intervention d'ingénierie. C'est sa proposition de valeur fondamentale pour les équipes marketing et analytiques. Du point de vue de la sécurité, cette même fonctionnalité signifie qu'un seul ID de conteneur dans un modèle de site constitue un contexte d'exécution ouvert pour toute personne disposant des droits de publication sur ce conteneur. Pour illustrer l'ampleur du problème : un seul conteneur GTM peut lancer 48 scripts enfants ou plus, et chacun de ces scripts peut charger d'autres dépendances. La chaîne de chargement du fournisseur est une arborescence, pas une liste, et la plupart des équipes de sécurité ne connaissent que la racine.
Lorsque les équipes de sécurité auditent leur surface d’attaque, elles se concentrent généralement sur :
- Infrastructure côté serveur et API
- Authentification et gestion de session
- Scripts tiers connus dans la base de code
Ce qui est rarement audité, c'est l'inventaire des conteneurs GTM lui-même : quels ID de conteneur sont actifs sur quels domaines, qui a un accès à la publication et quelles balises sont actuellement configurées pour se déclencher. Pour une plateforme multimarque comptant 70 à 200 domaines, cet inventaire n'est quasiment jamais maintenu avec une rigueur sécuritaire.
Le ENISA Threat Landscape for Supply Chain Attacks identifie les scripts tiers et la compromission des dépendances comme l'une des principales catégories d'attaques croissantes. Les conteneurs GTM sont au centre de ce risque car ils sont à la fois approuvés par le navigateur, contrôlés par du personnel non chargé de la sécurité et capables d'exécuter du code arbitraire. Pour avoir une vision plus large de la façon dont les dépendances tierces deviennent des vecteurs d’attaque avant qu’elles n’atteignent votre gestionnaire de balises, le modèle d’attaque de la chaîne d’approvisionnement mérite d’être compris à part entière.
Comment les conteneurs Shadow GTM apparaissent sur les plateformes de jeu
Réponse rapide : Les conteneurs fantômes atteignent les domaines iGaming via quatre voies principales : les équipes affiliées intègrent leurs propres identifiants de conteneur lors de la configuration de la campagne, le personnel de l'agence ajoute des conteneurs aux lancements de nouvelles marques sans examen technique, les informations d'identification compromises donnant aux attaquants l'accès au compte GTM et les raccourcis de développeur où un identifiant de conteneur de test est promu en production et n'est jamais supprimé.**
Le terme « ombre » n’implique pas nécessairement une intention malveillante au point d’insertion. De nombreux conteneurs fantômes sont au départ des décisions opérationnelles légitimes qui n’ont jamais été nettoyées ou révisées. Mais ils créent des contextes d’exécution persistants et non surveillés qui peuvent être exploités longtemps après la fin de leur objectif initial.
Voici les quatre origines les plus courantes observées sur les plateformes multimarques iGaming :
-
Le conteneur de l'équipe d'affiliation ajoute : une équipe de marketing à la performance conclut un accord avec un réseau d'affiliation qui nécessite un pixel déclenché via GTM. L'affilié fournit son propre identifiant de conteneur. Le marketing l'ajoute directement au modèle de domaine sans générer de ticket de sécurité. Le conteneur se déclenche sur toutes les pages destinées aux joueurs à partir de ce moment.
-
Lancements de nouvelles marques : lors d'un lancement de marque rapide, une agence ou un développeur ajoute un conteneur GTM temporaire à l'analyse et au suivi des prototypes. Après le lancement, le conteneur reste actif car personne n'est propriétaire de la tâche de déclassement.
-
Identifiants GTM compromis : un acteur malveillant accède à un conteneur GTM autorisé existant via un entrepreneur marketing hameçonné ou une attaque de credential stuffing sur un compte Google lié au conteneur. Ils publient une nouvelle balise malveillante dans un conteneur déjà approuvé.
-
Raccourcis des développeurs : un ID de conteneur d'assurance qualité ou de préparation est codé en dur dans un modèle partagé lors de la création d'un site. Lorsque le modèle est mis en ligne sur plusieurs domaines, le conteneur intermédiaire l'accompagne, et les conteneurs intermédiaires ont généralement un accès de publication moins contrôlé.
Dans tous ces cas, les journaux réseau de la plateforme affichent la même entrée : une requête GET réussie à www.googletagmanager.com/gtm.js?id=GTM-XXXXXXX. L'ID du conteneur est visible dans l'URL mais n'est pas référencé automatiquement par rapport à un inventaire approuvé.
Qu'est-ce qui peut s'exécuter à l'intérieur d'un conteneur non autorisé
Réponse rapide : À l'intérieur d'un conteneur GTM non autorisé, un attaquant peut déployer des scripts pixel qui exfiltrent les informations personnelles du joueur vers des réseaux publicitaires tiers, injecter du code de redirection qui détourne les joueurs vers des sites concurrents, installer des skimmers de champs de formulaire sur les pages de dépôt, exécuter un suivi des affiliés fantômes qui détourne l'attribution des conversions ou charger des charges utiles malveillantes supplémentaires à partir de domaines externes, le tout sans empreinte côté serveur.**
La gamme de charges utiles qu'un conteneur GTM peut fournir n'est limitée que par ce que JavaScript peut faire dans le navigateur. En pratique, quatre catégories de charges utiles sont les plus pertinentes pour les plateformes iGaming.
Tout d’abord, les pixels de suivi des ombres. Un conteneur peut déclencher des événements de pixel Facebook, TikTok ou LinkedIn avec des identifiants de pixel non propriétaires. Pour un opérateur de jeux de hasard qui ne peut pas légalement faire de la publicité sur ces plateformes, il s'agit à la fois d'une violation du GDPR et d'une violation de la politique publicitaire, et l'opérateur peut ignorer complètement ce qui se produit.
Deuxièmement, les scripts de redirection des joueurs. Comme détaillé dans le contexte du détournement du parcours du joueur, une balise HTML personnalisée à l'intérieur d'un conteneur GTM peut intercepter les événements de clic sur les boutons de dépôt, les formulaires de connexion ou les CTA bonus et rediriger les joueurs vers une destination concurrente. Le système de déclenchement intégré au conteneur permet de limiter facilement cette opération à des pages, des appareils ou des segments d'utilisateurs spécifiques.
Troisièmement, formez des écumeurs de terrain. Sur les pages de dépôt ou KYC où les joueurs saisissent les détails de leur carte ou leurs documents d'identité, une balise GTM peut attacher des écouteurs d'événements aux champs de saisie et exfiltrer les valeurs saisies vers un point de terminaison distant. Il s'agit d'un équivalent au niveau du navigateur des attaques de style Magecart, exécutées sans toucher au code côté serveur.
Quatrièmement, les scripts de chargement. Une balise de conteneur peut charger des fichiers JavaScript externes supplémentaires, transformant ainsi le conteneur GTM en un compte-gouttes de charge utile de premier étage. Le domaine servant la charge utile supplémentaire peut ne figurer sur aucune liste de blocage au moment du chargement, ce qui rend la détection de la couche réseau peu fiable.
Pourquoi les outils existants manquent d'activité de conteneur fantôme
Réponse rapide : Les outils de surveillance réseau et les solutions de couche CDN constatent que GTM.js a été chargé avec succès depuis l'infrastructure de Google. Ils ne voient pas quels ID de conteneur étaient actifs, quelles balises ont été déclenchées dans ces conteneurs ou quel JavaScript ces balises ont exécuté après le chargement. La surface d'attaque réside entièrement dans le runtime JavaScript du navigateur, une fois la transaction réseau terminée.**
C’est cette lacune architecturale qui fait des conteneurs shadow GTM un risque persistant et sous-traité. Le tableau ci-dessous mappe chaque outil commun à ce qu'il peut et ne peut pas observer dans un scénario fantôme GTM.
| Catégorie d'outils | Ce qu'il PEUT voir | Ce qu'il NE PEUT PAS voir |
|---|---|---|
| Content Security Policy (CSP) | Si les scripts se chargent à partir de domaines autorisés | Quel ID de conteneur est en cours d'exécution ; quel code s'exécute dans un domaine autorisé |
| Web Application Firewall (WAF) | En-têtes et corps de requête/réponse HTTP | JavaScript s'exécutant dans un onglet du navigateur après le chargement de la page |
| Analyse du trafic réseau | Ce gtm.js chargé ; ID du conteneur dans l'URL de la demande | Quelles balises se sont déclenchées à l’intérieur du conteneur ; ce que ces balises ont exécuté ; ressources externes chargées après l'initialisation |
| Outils de développement de navigateur (manuel) | Comportement d'exécution complet sur un seul domaine à un moment donné | Comportement d'exécution sur 70 à 200 domaines en continu ; modifications de balises publiées dynamiquement |
Dans notre surveillance des plateformes de jeux multimarques, l’écart en matière d’identification des conteneurs est systématiquement plus large que ce que les opérateurs prévoient. Les équipes de sécurité disposent souvent d'enregistrements formels pour moins de la moitié des identifiants de conteneurs que nous observons s'exécuter dans leurs portefeuilles de domaines. L’écart s’accroît avec l’échelle de la plateforme, et il s’accroît plus rapidement que la plupart des processus de gouvernance ne peuvent le suivre.
La divulgation Sansec polyfill.js de juin 2024, qui a touché plus de 490 000 sites, constitue un parallèle instructif. Chacun de ces sites avait chargé ce qui semblait être une bibliothèque légitime et largement utilisée à partir d'un CDN fiable. Les journaux réseau ont montré une réponse propre et réussie. La charge utile malveillante n’est devenue visible que lorsque quelqu’un a regardé ce que faisait réellement JavaScript dans le navigateur. Les conteneurs Shadow GTM suivent le même modèle : la couche réseau signale une charge propre de l'infrastructure de Google, et tout ce qui suit est invisible sans instrumentation de la couche navigateur.
Comment cside identifie chaque conteneur et chaque script dans tous les domaines
Réponse rapide : cside instrumente 100% de sessions utilisateur réelles au niveau du navigateur, ce qui signifie qu'il voit chaque ID de conteneur GTM se charger sur chaque domaine de votre portefeuille, chaque balise qui se déclenche dans chaque conteneur et chaque script que ces balises exécutent ou chargent. Lorsqu'un nouvel ID de conteneur apparaît ou qu'un conteneur connu exécute un nouveau type de charge utile, cside déclenche une alerte en temps réel avec un contexte d'exécution complet.**
Pour les plateformes multimarques, cside fournit un inventaire de scripts unifié sur l'ensemble du portefeuille de domaines. Plutôt que d'exiger un audit manuel de chaque compte GTM, la plateforme fait apparaître la réalité d'exécution : ce qui s'exécute réellement dans les navigateurs des joueurs, en ce moment, sur chaque domaine.
Capacités spécifiques pertinentes pour la détection des ombres GTM :
- Énumération des ID de conteneur : cside identifie chaque ID de conteneur GTM distinct observé en cours de chargement dans tous les domaines surveillés, en signalant ceux qui n'étaient pas présents dans l'instantané d'inventaire précédent.
- Mappage d'exécution des balises : pour chaque conteneur, cside cartographie les balises HTML personnalisées et les balises de chargement de script qui se déclenchent, ainsi que les domaines externes qu'elles contactent.
- Alerte de nouvelle charge utile : lorsqu'un conteneur qui a été observé précédemment commence à exécuter un nouveau modèle de script ou à contacter un nouveau domaine externe, une alerte est immédiatement déclenchée.
- Corrélation entre domaines : si un ID de conteneur fantôme apparaît simultanément sur plusieurs domaines, cside identifie le modèle, ce qui est utile pour détecter les attaques coordonnées lors du lancement de nouvelles marques ou du déploiement de campagnes d'affiliation.
- Couverture de session 100% : étant donné que cside instrumente chaque session, et non un échantillon, il capture les conditions d'attaque qui ne se déclenchent que pour des segments d'utilisateurs, des appareils ou des zones géographiques spécifiques.
- Profils d'autorisation par fournisseur : une fois qu'un conteneur fantôme est identifié et placé sous gouvernance, les opérateurs peuvent attribuer à chaque fournisseur chargé par GTM son propre profil d'autorisation avec des capacités contrôlables spécifiques. Cela signifie qu'une balise d'analyse chargée via GTM peut être empêchée d'accéder aux champs de paiement, à l'API de demande de paiement ou à localStorage, même si le code du fournisseur est compromis ultérieurement.
cside ne s'appuie pas sur une surveillance basée sur un proxy ou sur un échantillonnage passif du trafic réseau. L'instrumentation s'exécute à l'intérieur du navigateur, lui donnant le même point de vue que les scripts qu'il surveille.
Ce que la première séance de monitoring a révélé
Lorsque nous avons organisé la première session de surveillance cside sur une importante plateforme de jeu en ligne multimarque européenne plus tôt cette année, l'une des premières choses qui sont apparues sur le tableau de bord était un ensemble d'identifiants de conteneur GTM dont aucun membre de l'équipe de sécurité ne pouvait tenir compte. La plateforme exploitait plus de 70 marques de casinos et de paris sportifs, et l’équipe de sécurité pensait avoir une maîtrise raisonnable de son patrimoine de gestionnaires de balises. Ce que montrait l’inventaire de la couche navigateur était différent. Dès le premier jour de surveillance du domaine de marque initial, cside a identifié plusieurs ID de conteneur actifs qui avaient été ajoutés par l'équipe marketing sans passer par aucun processus d'examen de sécurité. Les conteneurs se chargeaient depuis des mois sur des pages destinées aux joueurs en direct.
L'équipe de sécurité n'a pas été informée car l'équipe marketing ne savait pas qu'une notification était requise. Il n’existait aucun processus établi reliant les modifications du gestionnaire de balises à la surveillance de la sécurité. Chaque conteneur avait été ajouté dans le contexte d'une campagne légitime ou d'un accord d'affiliation et n'avait tout simplement jamais été examiné ou supprimé. Dans les 24 heures suivant le début de la session de surveillance, la plateforme disposait de son premier inventaire d'exécution complet de chaque conteneur exécuté dans le domaine de test, et un plan de remédiation était en cours pour les conteneurs non examinés. Le commentaire de la plateforme après la session : c'était la première fois qu'ils voyaient l'ensemble de leurs scripts de couche navigateur en un seul endroit.
Résumé
Les conteneurs Shadow GTM constituent un échec de gouvernance qui crée une exposition à la sécurité. Les conteneurs arrivent via des canaux opérationnels normaux, se chargent à partir d'une infrastructure Google fiable et sont invisibles pour tous les outils de surveillance qui ne s'exécutent pas dans le navigateur. Pour les plateformes multimarques, la seule approche fiable est une instrumentation continue au niveau du navigateur qui maintient un inventaire en direct de chaque ID de conteneur, de chaque balise et de chaque script exécuté sur l'ensemble du portefeuille de domaines. Un audit à un moment donné sera toujours obsolète au moment où le prochain conteneur sera ajouté. La capacité de sécurité côté client de cside fournit cet inventaire continu, et pour plus de détails sur la manière dont les charges utiles de redirection sont transmises via ces conteneurs, consultez notre guide sur les attaques de redirection de scripts malveillants sur les plateformes de casino.
