Google Tag Manager: Risiken durch Custom-JS

Der Google Tag Manager (GTM) ist ein mächtiges Tool: Marketing- und Analyse-Teams können Tags und Skripte ohne Entwicklerdeployments einbauen. Genau diese Flexibilität birgt aber auch Risiken. Custom-HTML- oder Custom-JS-Tags können, wenn sie missbräuchlich eingesetzt werden, Daten abgreifen, Nutzer manipulieren oder Dritt-Domains nachladen. In diesem Beitrag erkläre ich, welche Risiken bestehen, wie man GTM sicher betreibt, wie man Missbrauch erkennt und wie man im Verdachtsfall reagiert — verantwortungsbewusst und legal.

Warum GTM ein attraktives Angriffsvektor ist

• Zentraler Ausführungsort: GTM-Container laufen auf allen Seiten einer Domain — ein kompromittiertes Tag wirkt sofort überall.
• Dynamische Ausführung: Custom-JS kann DOM-Inhalte lesen/verändern, Formulare auslesen oder Netzwerkaufrufe starten.
• Oft weitreichende Berechtigungen: Viele Seiten vertrauen Skripten, die über GTM geladen werden (z. B. Analytics, A/B-Tests).
• Betriebspraxis: Marketing-Teams haben manchmal Publish-Rechte ohne strenge Review-Prozesse.

Typische Missbrauchsszenarien

• Datenexfiltration: Unautorisierte Sammlung und Versand von Eingabefeldern (z. B. E-Mail, Zahlungsinfo).
• Content-Manipulation: Anzeigen oder Links werden ersetzt, Phishing-Inhalte eingeblendet.
• Supply-chain-Angriffe: GTM lädt bösartige Skripte von kompromittierten Drittanbietern nach.
• Persistent tracking / fingerprinting: Erweiterte Nachverfolgung, die über erlaubte Tracking-Zwecke hinausgeht.

Prinzipien für sicheren GTM-Betrieb

1. Least privilege: Nur die nötigsten Personen erhalten Publish- oder Edit-Rechte. Trenne Rollen (Lesen / Testen / Veröffentlichen).
2. Review & Approval: Jede Änderung — besonders Custom HTML/JS — durchläuft ein Review-Prozess mit Entwickler- oder Security-Sign-off.
3. Vermeide Custom HTML, wenn möglich: Nutze vordefinierte Tag-Templates oder server-seitiges Tagging.
4. Versionskontrolle & Preview: Nutze Workspaces, Vorschau und Versioning; teste Änderungen in Staging-Umgebung.
5. Monitoring & Logging: Überwache Container-Änderungen, setze Alerts und prüfe Netzwerktraffic auf ungewöhnliche Targets.
6. Sicherheitsrichtlinien durchsetzen: Content Security Policy (CSP), Subresource Integrity (wenn möglich), SameSite-Cookies, etc.

Konkrete technische Maßnahmen

1. Limitieren, wer was darf
   Nutze GTM-Bereiche/Workspaces und verteile Rollen restriktiv.
   Implementiere einen Change-Approval-Workflow (z. B. in deinem Ticketing-System) — keine direkten Publishes ohne Ticket und Review.
2. Tag-Design: Vorlagen statt freier JS
   Erstelle und verwende Custom Tag Templates (GTM Template) mit streng definierten Eingaben, statt Raw-Custom-HTML.
   Templates können einschränken, welche Netzwerkanfragen erlaubt sind, und dadurch Risiken verringern.
3. Server-seitiges Tagging
   Wo möglich, verschiebe sensible Logik auf server-seitiges Tag-Management (GTM Server Container). Dadurch laufen kritische Skripte nicht mehr im Browser des Nutzers.
4. Content Integrity & vertrauenswürdige Hosts
   Soweit möglich, verwende Signaturen/Hashes (SRI) für statische Dateien. Für dynamisch geladene Tags ist SRI oft nicht praktikabel, daher ist ein whitelisting von Domains sinnvoll.
   Beschränke externe Domains, an die GTM Daten senden kann, per CSP und Netzwerkpolicies.
5. Content Security Policy (CSP) konfigurieren
   Eine CSP kann das Risiko deutlich senken, indem nur Scripts von erlaubten Quellen ausgeführt werden. Beispiel für eine restriktivere Policy (als Startpunkt; an deine Infrastruktur anpassen):

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://www.google-analytics.com;
  connect-src 'self' https://www.google-analytics.com https://your-trusted-endpoints.example.com;
  frame-src 'self' https://www.youtube.com;
  img-src 'self' data: https:;
  style-src 'self' 'unsafe-inline';
  object-src 'none';
  base-uri 'self';
  form-action 'self';

Hinweise:

script-src listet die erlaubten Script-Quellen; jede weitere Domain, die GTM lädt, muss bewusst freigeschaltet werden.
CSP kann durch report-uri/report-to erweitert werden, um Verstöße zu bekommen.
CSP ist mächtig, aber komplex — teste in Report-Only-Mode zuerst.