Thema: Content Security Policy (CSP), Google Tag Manager (GTM), unsafe-inline, Nonce, Hash, Trackingprobleme
Zugegeben, Marketing und IT-Security begegnen sich selten – aber wenn doch, dann meist wegen der CSP. Und die steht häufig im Konflikt mit dem Google Tag Manager, den Online-Marketer für alles von der Integration externer Tools bis zum Conversion-Tracking für Suchmaschinen- und Social-Media-Kampagnen nutzen.
Hier erfährst du deshalb, was du als Digital Marketing Manager über Content Security Policies wissen musst. Und lernst alles was notwendig ist, damit du meinen Praxisguide „Google Tag Manager mit Content-Security-Policy nutzen“ folgen kannst oder Probleme beheben kannst, wenn deine CSP zu Problem mit Social Media Pixel oder externen Tools führen. [Coming soon]
Was ist eine CSP
Eine Content Security Policy ist eine Sicherheitsrichtlinie, die verhindern soll, dass externe Inhalte – z.B. Skripte, Bilder oder eingebettete Inhalte – unerlaubt in eine Webseite ausgeführt werden. Die CSP legt genau fest, welche Quellen für bestimmte Inhaltstypen (z.B. Skripte, Styles, Medien oder Einbettungen) auf dieser Webseite erlaubt sind. Die wichtigsten Regeln, zumindest im Kontext des Google Tag Managers, sind:
- 'self': Erlaubt für diesen Inhaltstyp nur Inhalte, die direkt von der eigenen Domain geladen werden
- Domains & URLs: Erlaubt nur Inhalte von definierten Domains (z.B. https://beispiel.ch, *.beispiel.ch) oder Protokollen (z.B. https)
- 'none': Verbietet diesen Inhaltstyp vollständig
- 'unsafe-inline': Erlaubt Inline-Inhalte, die direkt im HTML-Dokument stehen – dazu aber später mehr
- Nonce/Hash: Erlaubt ausgewählte Inline-Inhalte, die durch ein „Passwort“ freigegeben wurden – wie das funktioniert, erkläre ich in meinem GTM & CSP Guide
Info: Ein Nonce («number used once») ist ein einmaliger zufälliger Token der beim Laden der Seite generiert wird. Quasi ein Einmal-Passwort für die Ausführung des Scripts. Ein Hash hingegen ist eine Art «Prüfsumme» oder ein Fingerabdruck für dein Script. Der Hash stimmt nur, wenn der Inhalt des Scripts unverändert ist und verhindert so Manipulation.
Wenn ein Nutzer eine Webseite mit Content Security Policy aufruft, sendet der Server die CSP als HTTP-Header an den Browser. Der Browser prüft dann beim Laden jedes Inhalts, ob er laut Richtlinie erlaubt ist. Ist das nicht der Fall, wird der Inhalt blockiert.
Eine Content Security Policy schützt daher in erster Linie vor Angriffen wie Cross-Site Scripting (XSS) und anderen Angriffen. Ohne CSP könnte ein Angreifer beispielsweise über ein unsicheres Formular ein Skript einschleusen, das Nutzerverhalten an Dritte sendet, oder über ein kompromittiertes Drittanbieter-Skript Schadsoftware auf den Computer des Nutzers nachladen.
Das Problem mit dem Google Tag Manager
Vielleicht hast du den gordischen Knoten schon erkannt: Einer der Vorteile des Google Tag Managers ist es, dass Marketer möglichst einfach Scripte oder externe Tools auf ihrer Webseite einbinden können, ohne den Code direkt in die Seite schreiben zu müssen. So kann man problemfrei sein Event-Tracking jederzeit anpassen, herumprobieren und ist nicht auf Entwickler angewiesen. Genau das, versucht eine CSP eigentlich zu unterbinden. Dass der Initialisierungscode des Tag Managers selbst normalerweise als Inline-Skript in den Head der Webseite eingebunden ist, ist ebenfalls problematisch, wenn Inline-Script per CSP verboten ist.
Der Effekt ist meist, dass die Konsole einen Fehler anzeigt:
Oder schlimmer noch: Das Tracking funktioniert nicht mehr und keiner weiss wieso. Der Grund ist vermutlich, dass dein GTM-Snippet und/oder vom GTM ausgeführte Tags blockiert wurden.
Der gefährliche Shortcut: 'unsafe-inline'
Weiter oben habe ich bereits die 'unsafe-inline' Regel erwähnt. Und auf den ersten Blick ist sie vielversprechend, da sie erlaubt, dass dein blockiertes GTM-Snippet wieder ausgeführt werden kann. Von der Verwendung von 'unsafe-inline' (oder, schlimmer noch, 'unsafe-eval' – im Marketingkontext allerdings selten notwendig) wird allerdings abgeraten und das aus gutem Grund: Die 'unsafe-inline' Regel erlaubt, gerade bei Scripts, das vorhandene Schwächen in deiner Seite ausgenutzt werden.
Beispiel: Deine Seite hat ein Formular und eine Bestätigungsseite, auf der Nutzer seine Eingaben überprüfen können. Wenn dein Formular unsauber gebaut ist und die Nutzereingaben nicht bereinigt, besteht hier die Gefahr, dass ein bösartiger Akteur einfach ein Script seiner Wahl in das Formular eingibt. Sobald die eingegebenen Inhalte auf der Bestätigungsseite angezeigt werden soll, führt deine Webseite den eingeschleusten Code aus und macht, was auch immer der bösartige Akteur möchte. Wäre 'unsafe-inline' verboten, würde das Script gar nicht laufen, da es keine separate Datei auf deinem Server ist.
script-src 'unsafe-inline' untergräbt also einen der wichtigsten Sicherheitsmechanismen der Content Security Policy. Klar, andere Angriffsvektoren – z. B. 'unsafe eval', die Einbindung von unauthorisierten Trackingpixel durch Angreifer oder die Gefahr, dass Laden komplexer, beliebig aktualisierbarer Schadsoftware aus einer Drittquelle – werden verhindert, aber die Türe per Inline-Script steht bösen Akteuren immer noch offen.
Bei kommerziellen Seiten, gerade solchen die Nutzerinput erlauben, oder bei Webapplikationen sollte daher nie 'unsafe-inline' erlaubt werden. Mal zugespitzt formuliert: Wenn deine IT-Abteilung entschieden hat, dass eine CSP notwendig ist, stehen die Chancen gut, dass 'unsafe-inline' für deinen Use Case zu riskant wäre.
Info: 'unsafe-inline' ist bequem, aber gefährlich. In Dev- oder Testumgebungen kann sie nützlich sein – im Livebetrieb (v.a. bei Seiten mit Nutzereingaben oder Login) sollte sie, gerade für JavaScript nicht erlaubt werden.
Und jetzt?
Jetzt weisst du zumindest das Wichtigste, was du als Digital Marketing Manager über Content-Security-Policies wissen musst. Wenn du aktuell bereits in der Situation bist, ein CSP-basiertes Tracking-Problem lösen zu müssen, lasse ich dich aber nicht im Stich. Am besten schreibst du den Entwicklern deiner Webseite direkt, dass sie dir bei jedem Page Load einen Nonce generieren und in den DOM pushen sollen. Und Anschluss kannst du mein Tutorial lesen, was du im Tag Manager machen musst, damit alles wieder läuft.
Wenn du Hilfe bei der Umsetzung brauchst, melde dich gern – gemeinsam finden wir eine Lösung:
PS: Falls du ein technisch versierter Leser bist, warst du wahrscheinlich neugierig und hast bereits meine CSP überprüft. Und bemerkt, dass ich 'unsafe-inline' für Scripts erlaube. Erwischt! Der Blogartikel ist entstanden, als ich die CSP für meine eigene Seite eingerichtet habe. Und leider muss ich noch ein bisschen tech debt beseitigen, bevor ich bei mir dynamisch Nonces generieren kann.
© Der Hobbit – Eine unerwartete Reise, Warner Bros. / New Line Cinema / Metro-Goldwyn-Mayer
