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 Problemen mit Social-Media-Pixeln oder externen Tools führt.
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. Viele rein statische Seiten kommen vollständig ohne Inline-Skripte aus (Beachte hier bitte, dass das GTM-Initialisierungsskript selbst inline geladen werden muss – diesen Sonderfall beschreibe ich weiter unten). In solchen Fällen ist weder ein Nonce noch ein Hash erforderlich, solange alle benötigten Skripte aus klar definierten externen Quellen geladen werden. Aber wenn du Inline-Skripte nutzt, jedoch keine CSP definiert hast, 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-Scripte per CSP verboten sind.
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 meistens abgeraten. Wenn deine Webseite sensitive Informationen empfängt (beispielsweise Login-Masken oder andere Formulare, die vertrauliche Informationen empfangen) oder entsprechende Daten im Backend verarbeitet, gibt es dafür einen guten Grund: Die 'unsafe-inline'-Regel ermöglicht es Angreifern, vorhandene Schwachstellen deiner Seite leichter auszunutzen.
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 sollen, 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 unautorisierten Trackingpixeln 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, die Nutzereingaben erlauben, oder bei Webapplikationen sollte daher am besten kein 'unsafe-inline' erlaubt werden. Wenn deine Webseite allerdings ausschliesslich statische Inhalte liefert und keinerlei Nutzereingaben verarbeitet, ist eine besonders strenge CSP meist weniger kritisch. Aber - zugespitzt formuliert - wenn deine IT-Abteilung bereits 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 bei Seiten mit Nutzereingaben oder Login sollte sie aber, 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 pro Page Load einen Nonce erzeugen und im DOM verfügbar machen sollen. Im 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:
Oder lieber per E-Mail?
Ich antworte dir meistens innerhalb der nächsten paar Stunden. Wenn du möchtest, kannst du bereits erklären, um was es geht, und mir einen Link zu deiner Webseite hinterlassen.
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! Für mein aktuelles Risiko-Profil (statische Seite ohne Logins/Formulare) ist das - wie oben beschrieben - ein akzeptabler Trade-off. Für « echte » Webapplikationen würde ich es aber nicht so konfigurieren. 😉