Drittanbieter-Skripte sind ein Supply-Chain-Risiko
Ein Drittanbieter-Skript ist Code, den Sie nicht geschrieben haben, ausgeliefert von einer Firma, die Sie nicht kontrollieren, ausgeführt in Ihren Seiten mit den Sitzungen Ihrer Nutzer — in Supply-Chain-Begriffen: eine Abhängigkeit, die ihren eigenen Code jederzeit ändern kann, ohne Release, ohne Review, ohne Ankündigung. Im Oktober 2026 wurde dieses abstrakte Risiko, wie berichtet, zu einem konkreten Verlust, als ein Performance-Monitoring-Skript, das eine große Handelsseite lud, gegen eines ausgetauscht wurde, das gebaut war, um ihre Nutzer auszuräumen. Dieser Artikel geht durch, was berichtet wurde, was Subresource Integrity tatsächlich stoppt, warum das Fixieren einer Version vor ihrem Hash kommt, wann Selbst-Hosting die bessere Antwort ist, und die kurze Audit-Routine, die das Inventar ehrlich hält.
Was bei Polymarket geschah, wie berichtet
Am 29. Oktober 2026 versetzte Polymarkets internationale Site den Handel, wie berichtet, in den Nur-Stornieren-Modus, nachdem Nutzer gemeldet hatten, dass Gelder ihre Konten verließen, und der Handel wurde rund eine Stunde später wieder aufgenommen. Die eigenen Aussagen der Firma ordneten den Vorfall, wie berichtet, einem kompromittierten Drittanbieter zu, sagten, die Sache sei an die Strafverfolgung übergeben worden, und versprachen, betroffene Nutzer vollständig zu entschädigen. Berichte auf Grundlage der Postmortem der Firma vom 30. Oktober bezifferten den im Angriff Entnommenen Betrag auf etwa 2,7 Millionen Dollar, mit Gesamtrückerstattungen von 3,9 Millionen, sobald Kulanzzahlungen für Verluste durch die Handelspause eingerechnet waren; unabhängige On-Chain-Analysen, die in der Berichterstattung zitiert wurden, verfolgten eine ähnliche Summe, rund 2,7 Millionen, verteilt auf mehrere hundert Wallets. Keine dieser Zahlen ist hier unabhängig verifiziert — es sind die Zahlen der Berichterstattung, und dieser Artikel behandelt sie so.
Der Mechanismus ist, wie berichtet, der Teil, der sich verallgemeinern lässt. In der Berichterstattung zitierte Forscher brachten den bösartigen Code mit dem Real-User-Monitoring-Skript (RUM) eines Website-Performance-Anbieters in Verbindung — einer kleinen Datei, deren ganzer Job es ist, die Seitenladegeschwindigkeit in den Browsern der Besucher zu messen, pro Kunde vom CDN des Anbieters eingebettet. Diese Datei wurde, wie berichtet, durch eine Nutzlast ersetzt, die speziell für die Zielsite geschrieben war: Sie arbeitete in eingeloggten Sitzungen, nutzte die eigene Handelsmaschinerie der Site, die bereits in der Seite vorhanden war, und bewegte Positionen und Gelder zu einem vom Angreifer kontrollierten Ziel. Wie berichtet, war weder ein Smart-Contract-Fehler noch gestohlene Passwörter oder private Schlüssel im Spiel — das ausgetauschte Skript war, was den Browser betraf, schlicht die Seite selbst. Ob jedes Detail dieser Darstellung späterer Prüfung standhält, ist für die Lektion nebensächlich: Die Angriffsform — eine Anbieterdatei, einmal ausgetauscht, von jedem Besucher ausgeführt — ist die Standardform dieser Vorfallklasse.
Ein Drittanbieter-Skript ist Ihr Code, mit dem Release-Prozess eines anderen
Es gibt keine Sandbox in einem klassischen Skript-Tag. Code, der vom CDN eines Anbieters geladen wird, läuft in Ihrer Origin mit demselben Zugriff wie Ihr eigenes Bundle: Er kann das DOM lesen und ändern, Formularwerte beim Tippen lesen, Ihre APIs mit der Sitzung des Nutzers aufrufen und das Gefundene überallhin senden. Die OWASP-Anleitung zu JavaScript von Dritten nennt die drei Risiken schlicht — Verlust der Kontrolle über Änderungen an der Client-Anwendung, Ausführung beliebigen Codes auf Client-Systemen und Offenlegung sensibler Informationen an Dritte — und alle drei folgen aus dieser einen Tatsache. Ihr Review-Prozess, Ihr Code-Freeze und Ihr Änderungsgremium enden an Ihrem eigenen Build; die Datei des Anbieters kann der Anbieter bearbeiten, ein Angreifer, der den Anbieter kompromittiert, oder wer die Domain des Anbieters erneut registriert, falls sie je abläuft.
Diese Asymmetrie ist der Grund, warum „wir vertrauen diesem Anbieter“ keine Kontrolle ist. Vertrauen entscheidet, wessen Skript Sie heute akzeptieren; es sagt nichts darüber, was diese URL morgen ausliefert, und es gibt Ihnen kein Signal, wenn sich der Inhalt ändert. Die Kontrollen, die funktionieren, sind die, die das Vertrauen entweder beseitigen (die Datei selbst ausliefern), es einschränken (eine Content-Security-Policy, die begrenzt, was irgendein Skript tun und wohin es Daten senden darf) oder es bei jedem Laden mechanisch verifizieren — wofür Subresource Integrity da ist. Beginnen Sie mit dem Inventar: Sie können keine der drei Maßnahmen auf Skripte anwenden, von denen Sie nicht wissen, dass Sie sie haben, und die meisten Sites haben mehr, als ihre Eigentümer erwarten, sobald Marketing-Tags, Support-Widgets und Monitoring-Einbettungen gezählt sind.
Was SRI stoppt — und was es nicht stoppt
Subresource Integrity ist ein Browser-Mechanismus, vom W3C spezifiziert und von MDN dokumentiert: Die Seite gibt den kryptografischen Hash der Datei, die sie erwartet, im integrity-Attribut des Tags an, der Browser hasht das, was er tatsächlich heruntergeladen hat, und verweigert bei jeder Abweichung die Ausführung der Datei. Für eine ursprungsübergreifende Datei braucht das Tag außerdem crossorigin="anonymous", und der Server muss CORS-Header senden, damit der Browser die Prüfung vornehmen darf. Angewandt auf eine feste Bibliothek verwandelt SRI einen stillen Austausch in einen lauten Ausfall: Die ankommende Datei ist entweder byte für byte die Datei, die Sie geprüft haben, oder sie läuft überhaupt nicht. Wäre das Monitoring-Skript im berichteten Vorfall eine feste, so geladene Datei gewesen, wäre eine ausgetauschte Nutzlast an der Prüfung gescheitert, statt in den Sitzungen der Nutzer zu laufen — dieser Konditional ist die ehrliche Form der Behauptung, denn ob jene konkrete Einbettung hashbar war, ist eine Frage über eine dynamische Pro-Kunde-Datei, was genau der schwierige Fall unten ist.
Was SRI nicht stoppt, ist genauso wichtig. Es hilft nicht bei Skripten, deren Inhalt sich ändern soll — Tag-Manager-Container, Personalisierungs- und Consent-Loader, pro Kunde generierte Dateien —, weil es keinen stabilen Hash zum Fixieren gibt. Es beurteilt nicht die Datei, die Sie gehasht haben: Ein treu ausgeliefertes Skript kann nach Design immer noch neugierig, schlampig oder bösartig sein, und SRI wird es für immer fröhlich verifizieren. Es deckt keine Skripte ab, die andere Skripte zur Laufzeit injizieren, es schützt keine First-Party-Dateien von Ihrer eigenen Infrastruktur, und es tut nichts gegen die Daten, die ein legitimes Skript sammelt, sobald es läuft. SRI ist eine mechanische Garantie — exakt diese Bytes, oder nichts — und verdient seinen Platz neben, nicht anstelle von, CSP, Anbieter-Review und der Minimierung, wie viele Dritte von Anfang an Sitzungszugriff erhalten. Der Security-Headers-Check dieser Site bewertet die CSP-Seite dieser Paarung.
Fixieren Sie die Version, sonst kann der Hash nicht halten
SRI hat eine Vorbedingung, an der mehr Audits scheitern als an Bösartigkeit: Die URL muss immer dieselben Bytes zurückgeben. Ein Hash, fixiert über einer latest-Adresse, einer schwebenden Hauptversion oder einer Pro-Kunde-Datei, die der Anbieter regeneriert, ist ein Hash, der beim ersten Anbieter-Update bricht — und Teams, die ein selbst zugefügter SRI-Ausfall einmal geweckt hat, neigen dazu, das Attribut zu entfernen, statt die Adresse zu reparieren, und lassen die Seite schlechter zurück als ungemessen. Die dauerhafte Reihenfolge ist die umgekehrte: Ändern Sie zuerst die URL so, dass sie die exakte Version nennt ([email protected], /v2.4.0/), prüfen Sie diese Version einmal, und hashen Sie dann exakt diese Datei. Versionsanhebungen werden dann zu absichtlichen Ereignissen — neue URL, neuer Hash, ein Commit — statt zu Umgebungsänderungen, die Sie von Ihren Nutzern erfahren.
Fixieren hat einen Preis, und Ehrlichkeit verlangt, ihn zu nennen: Eine fixierte Bibliothek erhält keine stillen Sicherheitspatches mehr vom Anbieter, also schafft Fixieren die Pflicht, Releases zu verfolgen und absichtlich anzuheben — dieselbe Pflicht, die jede vendored Abhängigkeit mit sich bringt. Das ist eine handhabbare Pflicht — Release Notes und eine Kalendererinnerung decken sie ab — und sie ist strikt besser als die Alternative, die sie ersetzt, in der Updates ungeprüft im Tempo des Anbieters ankommen und Brüche unangekündigt in Ihrem. Behandeln Sie das Paar als eine Praxis: Das Fixieren macht den Inhalt adressierbar, der Hash macht ihn verifizierbar, und das Audit stellt sicher, dass keines von beiden still verfault ist — eine Versionszeichenkette, die eine CMS-Migration herauseditiert hat, ist so häufig wie ein fehlender Hash und nur geringfügig schwerer mit dem Auge zu bemerken.
Selbst-Hosting, und die Audit-Routine
Für die Skripte, die am meisten zählen, gibt es eine stumpfere Option: Liefern Sie die Datei selbst aus. Selbst-Hosting entfernt den Server, das Konto und die Domain des Anbieters vollständig aus Ihrer Laufzeit-Supply-Chain, lässt Ihre normale Deployment-Pipeline die Datei prüfen und hashen, und funktioniert weiter, wenn das CDN des Anbieters es nicht tut. Die Trade-offs sind real — Sie geben den Edge-Cache des Anbieters und automatische Updates auf, Sie übernehmen die Pflicht, seine Sicherheitsfixes selbst auszuliefern, und die Lizenzen mancher Anbieter oder ihre Pro-Kunde-Dateien erlauben es schlicht nicht — also ist die vernünftige Aufteilung nach Kritikalität: Hosten Sie kleine, feste Bibliotheken auf sensiblen Seiten selbst; fixieren und hashen Sie, was auf einem CDN bleibt; regieren Sie (mit Veröffentlichungsbeschränkungen, Änderungs-Review und CSP) die dynamischen Tags, die weder fixiert noch gehostet werden können; und löschen Sie auf Sicht jedes Skript, das niemand rechtfertigen kann. Jedes entfernte Skript ist eine Supply Chain, die Sie nicht mehr haben.
Die Routine, die das wahr hält, ist kurz genug, um sie tatsächlich zu laufen. Vierteljährlich — und nach jedem Redesign, jeder CMS-Migration oder jedem neuen Anbieter — führen Sie das Audit für Drittanbieter-Skripte & SRI über Ihre wichtigsten Seitentemplates aus: Es listet jedes Skript, auf das das statische HTML verweist, welche davon von Dritten sind, welchen Integrität fehlt und welche nicht fixiert sind, und berechnet ein einfügebereites sha384 für die ersten fehlenden Hashes, die es holen kann. Beheben Sie in Wirkungsreihenfolge — Sitzungs-, Zahlungs- und Seiten mit personenbezogenen Daten zuerst —, prüfen Sie dann die Transport- und Header-Schichten mit dem SSL-Grader und dem Headers-Check, und schließen Sie im Tag-Manager ab, dessen zur Laufzeit injizierte Skripte ein statisches Audit nicht sehen kann: Prüfen Sie seine Veröffentlicherliste und Änderungshistorie mit demselben Verdacht, den Sie einem Deploy-Log geben würden. Fünfzehn Minuten pro Vierteljahr, gegen eine Vorfallklasse, deren berichtete Kosten im obigen Fall binnen etwa einer Stunde in die Millionen liefen.