Audit für Drittanbieter-Skripte & SRI
Jedes Drittanbieter-Skript, das Ihre Seite lädt, läuft mit den vollen Rechten Ihrer Seite — es kann das DOM lesen, Formulareingaben beobachten und in den Sitzungen Ihrer Besucher handeln. Dieses Audit holt das statische HTML einer Seite, listet jedes externe Skript auf, auf das sie verweist, markiert, welche von Dritten stammen, welche einen Subresource-Integrity-Hash (SRI) tragen und welche auf eine exakte Version fixiert sind — und berechnet für Drittanbieter-Skripte ohne Integrität den sha384-Hash, damit Sie ihn direkt ins Tag einfügen können.
Zuletzt aktualisiert:
Sorgen Sie sich, dass ein Anbieterskript auf Ihrer Site sich ändern oder ausfallen könnte? Kostenlos mit myeventwatch überwachen — Ablauf- und Ausfallalarme, keine Karte nötig.
Was dieses Audit prüft — und was es nicht sehen kann
Der Checker holt die Seite einmal und parst das HTML, das ihm ausgeliefert wird — nur das statische HTML. Jedes <script src> in diesem Markup wird mit seinem Host aufgelistet, als First-Party eingestuft, wenn der Host zur registrierbaren Domain Ihrer Seite passt, und als Third-Party, wenn nicht, und auf die zwei Attribute geprüft, die entscheiden, ob der Browser Sie schützen kann: integrity, der SRI-Hash, den der Browser vor dem Ausführen der Datei verifiziert, und crossorigin, das ein ursprungsübergreifender SRI-Check zum Funktionieren braucht. Auch die Version in der URL wird bewertet: Ein Skript, adressiert als [email protected] oder /v2.4/, ist fixiert, während eine latest- oder unversionierte Adresse ein bewegliches Ziel ist, dessen Inhalt sich jederzeit ändern kann, ohne dass jemand Ihre Site anfasst.
Seien Sie sich über die Grenze im Klaren, denn sie zählt: Version 1 parst nur das statische HTML der Seite — Skripte, die JavaScript zur Laufzeit injiziert, sind nicht abgedeckt. Tag-Manager, Consent-Tools und Chat-Widgets erzeugen routinemäßig Skriptelemente aus Code, nachdem die Seite geladen hat, und ein statisches Parsing sieht sie nie. Betrachten Sie dieses Audit als das Inventar dessen, worauf Ihre Templates und Ihr CMS direkt verweisen — meist der größte und am leichtesten behebbare Teil des Problems — und prüfen Sie Tag-Manager-Container getrennt, in der Vorschau und Änderungshistorie des Managers selbst. Inline-Skripte (Blöcke ohne src) werden als Fakt im Ergebnis gezählt, weil sie überhaupt kein SRI tragen können; der Begleitartikel erklärt, was man mit ihnen tut.
Die Hash-Spalte: berechnet, niemals geraten
Für Drittanbieter-Skripte ohne integrity-Attribut holt der Checker das Skript selbst — über denselben SSRF-geschützten Abrufpfad wie jeder andere Checker auf dieser Site, gedeckelt auf die ersten 15 solcher Skripte und je 512 KB — und berechnet seinen SHA-384-Hash. Gelingt der Abruf, zeigt die SRI-Zelle das vollständige Snippet, integrity="sha384-…", bereit zum Einfügen in Ihr Tag neben crossorigin="anonymous". Ein Hash wird nur gezeigt, wenn das Skript tatsächlich geholt wurde. Schlug der Abruf fehl, war die Datei zu groß oder lag das Skript jenseits der 15er-Grenze, zeigt die Zelle stattdessen diesen Hinweis — niemals einen Platzhalter oder geratenen Wert — und die Lösung ist, den Hash in Ihrer eigenen Build-Pipeline zu erzeugen, wo die exakte Datei zur Hand ist.
Verwandte Prüfungen: Der Security-Headers-Check bewertet die Antwort-Header — einschließlich der Content-Security-Policy, SRIs natürlichem Partner —, der SSL-Grader deckt den Transport ab, über den diese Skripte ankommen, und der Begleitartikel Drittanbieter-Skripte sind ein Supply-Chain-Risiko führt durch einen echten Vorfall, was SRI stoppt und was nicht, und eine wiederholbare Audit-Routine.
So sind die Urteile zu lesen: Ein Drittanbieter-Skript mit Integrität und fixierter Version ist der gesunde Fall — der Browser wird eine ausgetauschte oder bearbeitete Datei ablehnen. Ein Drittanbieter-Skript ohne Integrität ist nicht automatisch bösartig; es ist ungeschützt, was bedeutet, dass sein Inhalt das ist, was sein Host heute ausliefert, und Ihre einzige Warnung vor einer Änderung wäre der Schaden selbst. Unfixierte Adressen verdienen denselben Verdacht wie fehlende Hashes, weil ein SRI-Hash über einer latest-URL beim ersten Anbieter-Update bricht — weshalb beide Befunde nebeneinander berichtet werden und weshalb die dauerhafte Lösung immer das Paar ist: erst die exakte Version fixieren, dann genau diese Datei hashen.
Die Fakten, die diese Seite zeigt
| Third-Party | Ein Skript, dessen registrierbare Host-Domain von der der Seite abweicht — Code, den ein anderer ausliefert und der mit den Rechten Ihrer Seite läuft. |
| Integrität (SRI) | Ob das Tag ein integrity-Attribut trägt: ein kryptografischer Hash, den der Browser vor dem Ausführen der Datei prüft und sie bei jeder Abweichung ablehnt. |
| Crossorigin | Ob das Tag das crossorigin-Attribut trägt, das ein ursprungsübergreifender SRI-Check erfordert; ohne es können Browser kein SRI auf den Ladevorgang anwenden. |
| Fixiert | Ob die URL eine exakte Version nennt ([email protected], /v2.4/) statt einer schwebenden latest- oder unversionierten Adresse, deren Inhalt sich still ändern kann. |
| Berechnetes SRI | Für Drittanbieter-Skripte ohne Integrität der sha384-Hash, den der Checker durch tatsächliches Holen der Datei berechnet hat — nur bei erfolgreichem Abruf gezeigt, für die ersten 15 solcher Skripte. |
Häufig gestellte Fragen
Sieht dieses Audit jedes Skript, das meine Seite ausführt?
Nein — und die Seite sagt das klar: Version 1 parst nur das statische HTML der Seite, also sind Skripte, die JavaScript zur Laufzeit injiziert, nicht abgedeckt. Tag-Manager, A/B-Test-Tools, Consent-Banner und Chat-Widgets injizieren Skripte üblicherweise nach dem Laden; prüfen Sie diese im Tag-Manager oder mit dem Netzwerk-Panel eines Browsers. Vollständig abgedeckt ist hier jedes Skript, auf das Ihr ausgeliefertes HTML direkt verweist — dort leben Bibliotheken, CDN-Widgets und Monitoring-Einbettungen.
Woher kommt der Hash in der SRI-Spalte?
Der Checker holt die Skriptdatei selbst und berechnet ihren SHA-384-Hash, für Drittanbieter-Skripte ohne integrity-Attribut — die ersten 15, je bis 512 KB. Ein Hash wird nur gezeigt, wenn das Skript tatsächlich geholt wurde: Schlug der Abruf fehl, war die Datei zu groß oder war die Grenze erreicht, zeigt die Zelle stattdessen diesen Hinweis. Fügen Sie das Snippet zusammen mit crossorigin="anonymous" in Ihr Skript-Tag ein und führen Sie das Audit nach jeder Versionsänderung erneut aus — eine neue Version bedeutet einen neuen Hash.
Mein Tag-Manager-Skript kann keinen festen Hash haben. Was dann?
Richtig — ein Tag-Manager-Container ist dafür gebaut, sich zu ändern, also kann SRI ihn nicht fixieren, und dasselbe gilt für jedes Skript, dessen ganzer Zweck das Laden veränderlichen Codes ist. Für diese sind die Kontrollen andere: Beschränken Sie, wer in den Container veröffentlichen darf, prüfen Sie seine Änderungshistorie wie Codeänderungen, laden Sie ihn nur auf den Seiten, die ihn brauchen, und nutzen Sie eine Content-Security-Policy, um zu begrenzen, was injizierte Skripte tun und wohin sie Daten senden dürfen. SRI schützt die festen Bibliotheken; Governance schützt die dynamischen.
Ist ein fehlendes integrity-Attribut ein Notfall?
Es ist eine ständige Exposition, kein Vorfall. Das Skript ist fast sicher die Datei, die der Anbieter heute ausliefern will; das Problem ist, dass nichts eine andere Datei morgen stoppen oder markieren würde — nach einer Anbieterkompromittierung, einem gekaperten Konto oder einer abgelaufenen Domain. Reihenfolge der Behebung: zuerst Skripte auf Seiten mit Logins, Zahlungen oder personenbezogenen Daten, dann fixierte und gehashte Bibliotheken überall sonst, dann der lange Schwanz. Jede Behebung ist eine einzeilige Tag-Änderung, sobald die Version fixiert ist.
Warum nennt die Fixiert-Spalte ein Skript „latest“ oder „unversioniert“?
Das Fixiert-Urteil ist eine heuristische Lesart der URL: Ein versionsähnliches Segment wie @1.2.3 oder /v2.4/ zählt als fixiert, ein explizites latest-Segment als schwebend, und eine URL ganz ohne Version als unversioniert. Es ist als Heuristik gekennzeichnet, weil nur der Anbieter sein Release-Schema kennt — aber der Sicherheitspunkt hängt nicht am Etikett: Wenn sich die Bytes an dieser URL ändern können, ohne dass sich die URL ändert, kann ein SRI-Hash nicht überleben, also erst fixieren, dann hashen.