Conteneurs Shadow GTM sur les plateformes de jeu multimarques : ce qu'ils sont et comment les détecter

Si votre plateforme gère 70 marques de casino ou plus, Google Tag Manager tourne quasi certainement sur chacun de ces domaines. Et sur l'ensemble de ces domaines, le nombre d'identifiants de conteneur actifs formellement examinés par votre équipe de sécurité est probablement bien inférieur au nombre réellement exécuté dans les navigateurs des joueurs. Cet écart, c'est le problème des conteneurs Shadow GTM. Au premier trimestre 2025, cside a détecté plus de 300 000 signaux d'attaque sur les sites surveillés, l'exécution non autorisée de scripts via des gestionnaires de balises constituant l'un des vecteurs d'attaque les plus constants du segment iGaming. En travaillant avec des opérateurs de jeux d'argent multimarques, j'ai constaté que cet écart entre les conteneurs connus des équipes de sécurité et ceux réellement exécutés dans les navigateurs des joueurs se creuse à chaque nouvelle marque ajoutée à un portefeuille.

Ce qu'est réellement un conteneur GTM et pourquoi il compte 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 first-party. Un identifiant de conteneur non autorisé sur votre domaine équivaut à accorder à un tiers inconnu un accès en écriture à votre interface destinée aux joueurs.**

Google Tag Manager est conçu pour permettre à des non-développeurs de déployer du JavaScript sur des sites en production sans intervention de l'ingénierie. C'est sa proposition de valeur fondamentale pour les équipes marketing et analytics. D'un point de vue sécurité, cette même caractéristique signifie qu'un simple identifiant de conteneur dans un modèle de site constitue un contexte d'exécution ouvert pour quiconque dispose des droits de publication sur ce conteneur. Pour mesurer l'ampleur du problème : un seul conteneur GTM peut déclencher 48 scripts enfants ou plus, et chacun de ces scripts peut charger d'autres dépendances. La chaîne de chargement des fournisseurs 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 :

• L'infrastructure côté serveur et les API
• L'authentification et la gestion de session
• Les scripts tiers connus présents dans la base de code

Ce qui est rarement audité, c'est l'inventaire des conteneurs GTM lui-même : quels identifiants de conteneur sont actifs sur quels domaines, qui dispose des droits de publication, et quelles balises sont actuellement configurées pour se déclencher. Pour une plateforme multimarque comptant de 70 à 200 domaines, cet inventaire n'est quasiment jamais maintenu avec la rigueur qu'exige la sécurité.

L'ENISA Threat Landscape for Supply Chain Attacks identifie la compromission de scripts et de dépendances tierces comme l'une des principales catégories d'attaques en pleine expansion. Les conteneurs GTM se trouvent au cœur de ce risque car ils sont à la fois approuvés par le navigateur, contrôlés par du personnel non spécialisé en sécurité, et capables d'exécuter du code arbitraire. Pour une vision plus large de la façon dont les dépendances tierces deviennent des vecteurs d'attaque avant même d'atteindre votre gestionnaire de balises, le schéma d'attaque de la chaîne d'approvisionnement mérite d'être compris en tant que tel.

Comment les conteneurs Shadow GTM apparaissent sur les plateformes de jeu

Réponse rapide : Les conteneurs fantômes atteignent les domaines iGaming par quatre voies principales : des équipes d'affiliation qui intègrent leurs propres identifiants de conteneur lors de la configuration d'une campagne, du personnel d'agence qui ajoute des conteneurs lors du lancement de nouvelles marques sans examen technique, des identifiants compromis donnant à des attaquants l'accès au compte GTM, et des raccourcis de développeurs où un identifiant de conteneur de test est promu en production et jamais retiré.**

Le terme « fantôme » n'implique pas nécessairement une intention malveillante au moment de l'insertion. De nombreux conteneurs fantômes naissent de décisions opérationnelles légitimes qui n'ont jamais été nettoyées ni réexaminées. Mais ils créent des contextes d'exécution persistants et non surveillés, exploitables longtemps après la fin de leur objectif initial.

Voici les quatre origines les plus fréquemment observées sur les plateformes iGaming multimarques :

• Ajout de conteneur par une équipe d'affiliation : une équipe de marketing à la performance conclut un accord avec un réseau d'affiliation qui exige 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 ouvrir de ticket de sécurité. Le conteneur se déclenche ensuite sur toutes les pages destinées aux joueurs.

• Lancement de nouvelles marques : lors d'un lancement de marque mené rapidement, une agence ou un développeur ajoute un conteneur GTM temporaire pour prototyper l'analytics et le suivi. Après le lancement, le conteneur reste actif car personne n'est chargé de sa mise hors service.

• Identifiants GTM compromis : un acteur malveillant obtient l'accès à un conteneur GTM autorisé existant via un prestataire marketing victime de phishing, ou via une attaque de credential stuffing sur un compte Google lié au conteneur. Il publie alors une nouvelle balise malveillante à l'intérieur d'un conteneur déjà considéré comme de confiance.

• Raccourcis de développeurs : un identifiant de conteneur de test ou de recette est codé en dur dans un modèle partagé lors de la construction d'un site. Lorsque le modèle est mis en production sur plusieurs domaines, le conteneur de recette part avec lui, et les conteneurs de recette bénéficient généralement d'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 vers www.googletagmanager.com/gtm.js?id=GTM-XXXXXXX. L'identifiant du conteneur est visible dans l'URL, mais n'est croisé avec aucun inventaire approuvé de manière automatisée.

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 de pixels qui exfiltrent les données personnelles des joueurs 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 d'affiliation fantôme qui détourne l'attribution des conversions, ou charger des charges utiles malveillantes supplémentaires depuis des domaines externes — le tout sans aucune empreinte côté serveur.**

L'éventail de charges utiles qu'un conteneur GTM peut livrer n'est limité 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.

Premièrement, les pixels de suivi fantômes. Un conteneur peut déclencher des événements de pixel Facebook, TikTok ou LinkedIn avec des identifiants de pixel qui ne sont pas ceux de l'opérateur. Pour un opérateur de jeux d'argent qui n'a pas légalement le droit de faire de la publicité sur ces plateformes, il s'agit à la fois d'une violation du RGPD et d'un manquement à la politique publicitaire — et l'opérateur peut totalement ignorer que cela se produit.

Deuxièmement, les scripts de redirection de joueurs. Comme détaillé dans le contexte du détournement du parcours 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 de bonus, et rediriger les joueurs vers une destination concurrente. Le système de déclencheurs intégré au conteneur permet de limiter facilement cela à des pages, des appareils ou des segments d'utilisateurs spécifiques.

Troisièmement, les skimmers de champs de formulaire. Sur les pages de dépôt ou de KYC où les joueurs saisissent les détails de leur carte ou des 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. C'est l'équivalent, au niveau du navigateur, des attaques de type Magecart, exécuté 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 dropper de charge utile de premier niveau. 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 au niveau réseau peu fiable.

Le schéma ci-dessus décompose ce même chargement de gtm.js en deux couches qui l'observent. La couche réseau s'arrête à une réponse propre ; la couche d'exécution est l'endroit où le conteneur fantôme accomplit réellement son travail.

Les quatre branches d'exécution dans lesquelles se déploie le conteneur — des pixels de suivi fantômes qui font fuiter des données personnelles vers des régies publicitaires, une redirection du joueur vers un concurrent, un skimmer de champs de formulaire sur les pages de dépôt et de KYC, et un script chargeur qui récupère une charge utile externe — sont exactement les quatre mécanismes décrits plus haut. Chacun s'exécute après le 200 OK, ce qui explique pourquoi un journal réseau propre ne constitue pas une preuve que le conteneur l'est aussi.

Pourquoi les outils existants passent à côté de l'activité des conteneurs fantômes

Réponse rapide : Les outils de surveillance réseau et les solutions au niveau du CDN constatent que gtm.js s'est chargé avec succès depuis l'infrastructure de Google. Ils ne voient pas quels identifiants de conteneur étaient actifs, quelles balises se sont déclenchées à l'intérieur de ces conteneurs, ni 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 faille architecturale qui fait des conteneurs Shadow GTM un risque persistant et sous-traité. Le tableau ci-dessous met en correspondance chaque catégorie d'outil courante avec ce qu'elle peut et ne peut pas observer dans un scénario de conteneur Shadow GTM.

Dans notre surveillance des plateformes de jeu multimarques, l'écart en matière d'identifiants de conteneur est systématiquement plus important que ce que prévoient les opérateurs. Les équipes de sécurité disposent souvent d'enregistrements formels pour moins de la moitié des identifiants de conteneur que nous observons s'exécuter sur leurs portefeuilles de domaines. Cet écart croît avec l'échelle de la plateforme, et il croît plus vite que la plupart des processus de gouvernance ne peuvent le suivre.

La divulgation Sansec sur 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, provenant d'un CDN de confiance. Les journaux réseau montraient une réponse propre et réussie. La charge utile malveillante n'est devenue visible que lorsque quelqu'un a examiné ce que le JavaScript faisait réellement dans le navigateur. Les conteneurs Shadow GTM suivent le même schéma : la couche réseau signale un chargement propre depuis l'infrastructure de Google, et tout ce qui suit reste invisible sans instrumentation au niveau du navigateur.

Comment cside identifie chaque conteneur et chaque script sur tous les domaines

Réponse rapide : cside instrumente 100 % des sessions utilisateur réelles au niveau du navigateur, ce qui signifie qu'il voit chaque identifiant 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 identifiant 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 le 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 révèle la réalité d'exécution : ce qui s'exécute réellement dans les navigateurs des joueurs, à l'instant même, sur chaque domaine.

Capacités spécifiques pertinentes pour la détection des conteneurs Shadow GTM :

• Énumération des identifiants de conteneur : cside identifie chaque identifiant de conteneur GTM distinct observé en cours de chargement sur tous les domaines surveillés, en signalant ceux qui n'étaient pas présents dans le précédent instantané d'inventaire
• Cartographie de l'exécution des balises : pour chaque conteneur, cside cartographie quelles balises HTML personnalisées et quelles balises de chargement de script se déclenchent, et quels domaines externes elles contactent
• Alerte sur nouvelle charge utile : lorsqu'un conteneur déjà observé auparavant commence à exécuter un nouveau schéma de script ou à contacter un nouveau domaine externe, une alerte est déclenchée immédiatement
• Corrélation entre domaines : si un identifiant de conteneur fantôme apparaît simultanément sur plusieurs domaines, cside identifie ce schéma, ce qui s'avère utile pour détecter des attaques coordonnées lors du lancement de nouvelles marques ou du déploiement de campagnes d'affiliation
• Couverture de 100 % des sessions : parce 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é via GTM son propre profil d'autorisation avec des capacités contrôlables spécifiques. Cela signifie qu'une balise d'analytics chargée via GTM peut se voir interdire l'accès aux champs de paiement, à l'API Payment Request ou au localStorage, même si le code du fournisseur venait à être compromis ultérieurement

cside ne repose pas sur une surveillance basée sur un proxy ni sur un échantillonnage passif du trafic réseau. Son instrumentation s'exécute à l'intérieur du navigateur, ce qui lui donne le même point de vue que les scripts qu'il surveille.

Ce que la première session de surveillance a révélé

Lorsque nous avons lancé 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 que le tableau de bord a fait apparaître était un ensemble d'identifiants de conteneur GTM dont personne, dans l'équipe de sécurité, ne pouvait rendre compte. La plateforme exploitait plus de 70 marques de casino et de paris sportifs, et l'équipe de sécurité pensait maîtriser raisonnablement son parc de gestionnaires de balises. Ce que l'inventaire au niveau du navigateur a révélé était différent. Dès le premier jour de surveillance du domaine de marque initial, cside a identifié plusieurs identifiants de conteneur actifs qui avaient été ajoutés par l'équipe marketing sans passer par le moindre processus d'examen de sécurité. Les conteneurs se chargeaient depuis des mois sur des pages en production destinées aux joueurs.

L'équipe de sécurité n'avait pas été informée car l'équipe marketing ignorait qu'une notification était nécessaire. Il n'existait aucun processus établi reliant les modifications du gestionnaire de balises à la supervision de la sécurité. Chaque conteneur avait été ajouté dans le cadre d'une campagne ou d'un accord d'affiliation légitime, et n'avait tout simplement jamais été réexaminé ni 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 actif sur le domaine test, et un plan de remédiation était engagé pour les conteneurs non examinés. Le commentaire de la plateforme après la session : c'était la première fois qu'elle voyait l'intégralité de son parc de scripts au niveau du navigateur réunie en un seul endroit.

Résumé

Les conteneurs Shadow GTM sont un échec de gouvernance qui crée une exposition de sécurité. Ces conteneurs arrivent par des canaux opérationnels normaux, se chargent depuis une infrastructure Google de confiance, et restent invisibles pour tout outil de surveillance qui ne s'exécute 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 identifiant de conteneur, de chaque balise et de chaque script exécuté sur l'ensemble du portefeuille de domaines. Un audit ponctuel sera toujours dépassé au moment où le conteneur suivant 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 livrées via ces conteneurs, consultez notre guide sur les attaques par redirection de scripts malveillants sur les plateformes de casino.