Signierte Konfiguration: warum der Tag-Manager eine Supply-Chain-Komponente ist und wie Ed25519 ihn ehrlich hält

Das Bedrohungsmodell

Drei Dinge können bei Konfiguration, die an Browser ausgeliefert wird, schiefgehen:

1. Jemand mit legitimem Zugriff liefert etwas Schädliches aus — ein Custom-HTML-Tag, das Formulardaten abzieht, ein „vorübergehendes“ Skript, das jahrelang bleibt.
2. Der Auslieferungsweg wird manipuliert — eine kompromittierte CDN-Edge, ein falsch konfigurierter Proxy, ein Man-in-the-Middle in einem feindlichen Netz.
3. Niemand kann sagen, was sich geändert hat — die Live-Konfiguration driftet von dem ab, was geprüft wurde.

Deklarative Templates schließen die erste Tür

Track hat keinen Custom-HTML- und keinen Custom-JavaScript-Tag-Typ. Jede browserseitige Aktion ist ein Template aus einem festen Satz (Meta-Pixel, Google-Tag, TikTok-Pixel, UET, Insight Tag und so weiter) mit typisierten Parametern: IDs, Event-Mappings, Consent-Zwecke. Ein Template kann keinen Code enthalten; es wählt einen Loader, den das SDK bereits mitbringt, und füllt Kennungen ein. Das Konfigurationsbundle ist Daten, serverseitig gegen ein Schema validiert und clientseitig erneut. Es gibt kein eval, kein new Function, und nichts in einem Bundle kann das SDK dazu bringen, ein Skript von einer URL zu laden, die das Template nicht ohnehin kennt.

Das ist ein bewusster Verlust an Flexibilität. Der Migrationsleitfaden listet, was kein Gegenstück hat; die Antwort lautet immer „diese Logik gehört in den Code der Site, wo sie wie Code geprüft wird“.

Signierung schließt die zweite

Wird eine Version veröffentlicht, serialisiert der Server das Bundle kanonisch, berechnet seinen SHA-256-Digest und signiert die Bytes mit einem Ed25519-Private-Key, der nur im Veröffentlichungsdienst existiert. Das veröffentlichte Artefakt ist { payload, digest, keyId, algorithm, signature }.

Das SDK bringt die Public Keys für die Key-IDs der Site mit. Bevor es ein Bundle anwendet, berechnet es den Digest neu, prüft ihn gegen den signierten und verifiziert die Signatur per Web Crypto (SubtleCrypto.verify mit Ed25519). Ein Bundle, das die Verifikation nicht besteht, wird verworfen, und das SDK behält sein zuletzt verifiziertes Bundle aus dem Sitzungscache — oder läuft ganz ohne Destinationen statt mit einer unverifizierten Konfiguration.

Signierung ersetzt TLS nicht; sie schützt vor allem, was TLS nicht abdeckt, einschließlich einer kompromittierten Edge, die gültig aussehendes JSON über ein gültiges Zertifikat ausliefert.

Das Manifest

Der Loader holt zuerst ein kleines Manifest: Tracking-ID, Umgebung, Version, Bundle-URL, Digest, Key-ID, Veröffentlichungszeitpunkt und das Kill-Switch-Flag. Das Manifest wird frisch geholt; das Bundle wird nach Version und Digest im Session Storage gecacht. Genau das lässt einen Kill-Switch oder ein Rollback beim nächsten Seitenaufruf wirken, ohne das Bundle selbst cache-busten zu müssen.

Versionierung schließt die dritte

Jede Veröffentlichung erzeugt eine unveränderliche Version mit Diff zum Vorgänger, dem Akteur, der Freigabe, die sie autorisiert hat, und der Request-ID. Die Versionshistorie zeigt genau, was Besucher erhalten, und ein Rollback veröffentlicht eine frühere Version als neue — erneut signiert, erneut auditiert. Entwürfe und veröffentlichte Versionen teilen nie denselben Speicher, sodass „was ist live“ eine einzelne Tatsache ist, nicht der Zustand mehrerer Schalter.

Schlüsselverwaltung

• Signierschlüssel werden je Umgebung erzeugt und verlassen den Veröffentlichungsdienst nie; der Private Key wird nie in der Datenbank gespeichert.
• Key-IDs ermöglichen Rotation: Ein neuer Schlüssel wird hinzugefügt, neue Versionen werden damit signiert, der alte Public Key bleibt zur Verifikation gültig, bis jede Site neu veröffentlicht hat, dann wird er stillgelegt.
• Die key_id auf jedem Manifest sagt dir, welcher Schlüssel die Live-Konfiguration signiert hat.

Was das für deine Sicherheitsprüfung bedeutet

Du kannst den Tag-Manager einem Sicherheitsteam in einem Absatz beschreiben: Er liefert signierte, schema-validierte Daten an ein festes SDK; er kann keinen von der Site geschriebenen Code ausführen; jede Änderung ist versioniert, freigegeben und zuordenbar; und eine Kompromittierung des Auslieferungswegs kann das Verhalten ohne den Signierschlüssel nicht ändern. Die Sicherheitsseite verlinkt die aktuellen Key-IDs und den Verifikationsquellcode des SDK.