Thema: Content Security Policy (CSP), Meta Pixel, LinkedIn Insight Tag, TikTok Pixel
In den ersten beiden Artikeln habe ich dir erklärt, was eine Content Security Policy (CSP) ist, warum sie dem Google Tag Manager gern mal einen Strich durch die Rechnung macht und wie du das Ganze ganz grundlegend lösen kannst. Vielleicht hast du auch schon umgesetzt, was dort beschrieben wurde: Dein GTM läuft wieder mit einem Nonce, Inline-Skripte funktionieren und das Grundtracking sendet wieder Daten.
Aber: Auch wenn das meiste bereits wieder läuft, scheint das Problem, das durch die CSP ausgelöst wurde, noch nicht komplett gelöst. Während dein GA4 bereits wieder Daten erhält, zeigt der Meta Business Manager wahrschienlich keine Conversions, oder einzelne Scripts, die über Custom HTML Tags ausgelöst werden, funktionieren immer noch nicht. Vielleicht hast du beim Testen auch eine Fehlermeldung wie diese hier erhalten:
Diese Fehlermeldung zeigt, dass deine CSP das Laden externer Ressourcen blockiert. Das ist absolut sinnvoll und gewollt – dass fremde Skripte einfach auf deiner Seite eingeschleust werden und unbeachtet im Browser deiner Websitebesucher laufen, soll ja eben genau unterbunden werden. Aber du hast trotzdem das Problem, dass dein Tracking nicht verhebt.
der Knackpunkt: Viele Tracking-Tools, insbesondere Social-Media-Pixel, funktionieren nur, weil sie Inhalte von externen Domains laden. Was für Meta, TikTok und Co. hilft, ihre Pixel granularer einzusetzen und leichter weiterentwickeln zu können, bereitet dir jetzt Probleme. Aber warum eigentlich?
Warum Nonce und Hash hier nicht helfen
Wir haben in den vorhergehenden Artikeln bereits gelernt, wie man Skripte mit Nonce oder Hash trotz CSP zum Laufen bekommt, wenn sie direkt im HTML stehen – z. B. das GTM-Snippet selbst oder Custom HTML Tags, die du per Google Tag Manager eingebunden hast.
Bei einigen Tools reicht das leider nicht. Wie du dir vielleicht vorstellen kannst, steckt beispielsweise hinter dem Meta Pixel deutlich mehr als das kurze Snippet, das im Google Tag Manager eingebunden ist.
Meta Pixel, LinkedIn Insight Tag, TikTok Pixel und viele andere Tools laden nach dem Initialisieren zusätzliche Skripte oder Ressourcen nach – also Inhalte, die nicht mehr Teil deines ursprünglichen HTML sind. Für diese Dateien greift weder der Nonce noch der Hash, weil sie vom Browser als separate Netzwerk-Requests behandelt werden.
Beispiel: Im Screenshot oberhalb darf ein Inline-Script mit Nonce ausgeführt werden, aber sobald das Skript versucht, https://connect.facebook.net/en_US/fbevents.js zu laden, prüft der Browser die CSP. Wenn dort diese Domain nicht erlaubt ist, wird das Laden blockiert – selbst wenn der Ursprungsskript-Block korrekt signiert war.
Kurz gesagt: Nonce und Hash lösen nur das Inline-Problem, scheitern aber trotzdem, wenn ein Tag von dir versucht, externe Ressourcen von ausserhalb nachzuladen.
Die Lösung: Whitelisting externer Quellen / Allow-List
Um dieses Problem zu lösen, gibt es eigentlich nur einen Weg: Die gezielt blockierten Ressourcen freizugeben, also ein «Whitelisting» für bestimmte, externe Domains zuzulassen. Ja nach Anbieter gibt es hier einige Standard-Domains, die in deiner Allow-List sein sollten:
- Meta Pixel: https://connect.facebook.net
- LinkedIn Insight Tag: https://snap.licdn.com
- TikTok Pixel: https://analytics.tiktok.com
- Google Tag Manager & Analytics: https://www.googletagmanager.com, https://www.google-analytics.com
Diese Quellen müssen in der CSP deiner Seite u.U. explizit freigegeben werden, damit das Tracking mit CSP trotz Nonce/Hash funktioniert. Typischerweise wird das mittels der Direktive script-src, manchmal auch img-src oder connect-src (je nachdem, welche Art von Ressource das Tool lädt) erledigt.
Hinweis: Viele Anbieter verwenden unterschiedliche Subdomains oder ändern ihre Skripte gelegentlich ab. Meta arbeitet z. B. mit verschiedenen Varianten von *.facebook.net. So verlockend es jetzt klingt, einfach eine Wildcard wie *.facebook.net zuzulassen, rate ich dir davon ab, da damit unter Umständen auch unerwünschte Domains freigegeben werden könnten und somit den eigentlich Zweck der CSP unterlaufen. Der sichere Weg ist, mit den bekannten, dokumentierten Domains zu starten und deine CSP bei Bedarf zu erweitern.
Reporting: Probleme erkennen und im Auge behalten
Wie bereits erwähnt, ändern sich externe Tools regelmässig, und es besteht die Gefahr, dass eine neue Quelle verwendet wird, die du nicht gewhitelistet hast. Das Problem lässt sich per CSP-Reporting lösen.
Das CSP-Reporting kann übrigens auch zu Testzwecken hilfreich sein. Manchmal sind verschiedene Quellen ineinander verschachtelt. Wenn dein Code-Snippet im GTM externe Quellen lädt, die darin erneut externe Quellen nachladen, passiert es häufig, dass ein notwendiger Allow-Eintrag untergeht. In Hinblick auf Reports stehen dir bei einer Content Security Policy zwei verschiedene Optionen zur Verfügung:
- Content-Security-Policy-Report-Only: Diese Version blockiert nichts, sondern meldet nur Verstösse direkt im Browser. Dieser Report ist ideal zum Testen, bevor man eine CSP «scharf schaltet» und schlimmstenfalls ungewollt das Tracking verhindert.
- report-uri oder moderner report-to: Mit dieser Variante kommuniziert der Browser explizit, welches Skript oder welche Ressource blockiert wurde, auf welcher Seite und wann.
Ein typischer Report sagt dir direkt, welche Seite betroffen war, welche Direktive verletzt wurde (z. B. script-src), welche Domains geblockt wurden, und enthält auch einen Zeitstempel und Browserinformationen. Mit diesen Angaben ist es für eine IT-Abteilung häufig überhaupt kein Problem, die CSP richtig zu konfigurieren. Ich empfehle allerdings, mehrere Iterationen durchzuführen: Wenn die Ausführung eines Skripts verhindert wird, besteht die Gefahr, dass der Report gar nicht auf darin enthaltene, zusätzliche externe Ressourcen ausschlägt.
Tipp: CSP-Reports mittels report-to können bei Bedarf sogar automatisiert an einen Webhook (z. B. in Microsoft Teams) geschickt werden. Dadurch teilt dir eine Messenger-Nachricht in Echtzeit mit, wenn dein Tracking von der CSP verhindert wurde – z.B. weil Meta eine neue CDN-Domain eingeführt hat.
Achtung: Achte auf Sonderfälle
Leider ist es damit noch nicht in jedem Fall getan. Ein klassisches Beispiel ist das Meta Pixel: Es lädt nicht nur Ressourcen von connect.facebook.net, sondern greift je nach Event, Gerät oder anderen Abhängigkeiten auf weitere Subdomains, beispielsweise graph.facebook.com, zu. Wenn du diese Domain in deiner CSP nicht freigegeben hast, bleiben bestimmte Requests blockiert – und damit auch einzelne Conversion-Events.
Ähnlich sieht es bei anderen Tools aus, die mehrere Dienste kombinieren, auf CDNs zurückgreifen oder sich, je nach Situation, unterschiedlich verhalten. Darum lohnt es sich, ausgiebig zu testen und in der Browserkonsole oder im Reporting genau zu prüfen, welche Domains tatsächlich blockiert werden.
Alles klar?
Wenn du alle drei Artikel beachtet hast, sollte deine Content Security Policy Sicherheitslücken verhindern, aber nicht dein Tracking-Setup lahmlegen. Wenn du trotzdem Hilfe benötigst, helfe ich dir aber gerne und stehe dir jederzeit für eine Beratung zur Verfügung.
