Subresource Integrity (SRI) für Drittanbieter-Skripte richtig einsetzen

1. Das Risiko: ein kompromittiertes CDN ändert Code unbemerkt

Viele Webseiten binden externe Bibliotheken, Analyse-Skripte oder Payment-Widgets nicht selbst gehostet ein, sondern laden sie direkt von einem Content Delivery Network eines Drittanbieters. Das spart Bandbreite und Wartungsaufwand, bringt aber eine implizite Vertrauensannahme mit sich: Der eigene Server hat keinerlei Kontrolle darüber, welcher Code tatsächlich unter der eingebundenen URL ausgeliefert wird, sobald der CDN-Betreiber selbst kompromittiert wird oder ein Angreifer Zugriff auf dessen Infrastruktur erlangt.

Ein solcher Angriff, oft als Supply-Chain-Angriff bezeichnet, muss nicht einmal die Zielseite selbst treffen, sondern nur einen einzigen, weit verbreiteten Drittanbieter-Dienst. Ändert der Angreifer den ausgelieferten JavaScript-Code, etwa um Kreditkartendaten aus Formularen abzugreifen, betrifft das automatisch jede Seite, die diesen Dienst einbindet, ohne dass am eigenen Code irgendetwas verändert wurde. Genau dieses Szenario adressiert Subresource Integrity direkt an der Browser-Ebene.

<!-- Skript mit SRI-Hash und crossorigin-Attribut einbinden -->
<script
  src="https://cdn.beispiel-anbieter.de/lib/chart.min.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"
  referrerpolicy="no-referrer">
</script>

<!-- Bei Abweichung des Hash-Werts blockiert der Browser
     die Ausführung des Skripts komplett und wirft einen
     Konsolenfehler, statt den manipulierten Code laufen zu lassen. -->

2. Wie SRI technisch funktioniert

Das integrity-Attribut enthält einen kryptografischen Hash-Wert der erwarteten Datei, berechnet mit einem der Algorithmen SHA-256, SHA-384 oder SHA-512, gefolgt von der Base64-kodierten Prüfsumme. Sobald der Browser die referenzierte Datei lädt, berechnet er selbst den Hash des tatsächlich empfangenen Inhalts und vergleicht ihn byte-genau mit dem im Attribut angegebenen Wert.

Stimmen beide Werte überein, wird das Skript wie gewohnt ausgeführt. Weicht auch nur ein einziges Byte ab, verweigert der Browser die Ausführung vollständig und meldet den Fehler in der Konsole, ohne dass eine Zeile des potenziell manipulierten Codes jemals läuft. Diese Prüfung findet vollständig client-seitig statt und erfordert keinerlei Änderung am ausliefernden Server, was SRI zu einer besonders einfach zu integrierenden Schutzmaßnahme macht.

3. Hash-Werte korrekt generieren

Der Hash-Wert wird einmalig aus der konkreten Version der Datei generiert, die tatsächlich eingebunden werden soll, und muss bei jeder inhaltlichen Änderung der Datei neu berechnet werden. Am zuverlässigsten geschieht das direkt aus der Kommandozeile mit OpenSSL, indem die Datei heruntergeladen und lokal gehasht wird, statt dem Anbieter blind zu vertrauen.

Viele seriosere CDN-Anbieter wie cdnjs oder jsDelivr liefern den passenden Integrity-Hash direkt zusammen mit der Einbindungs-URL auf ihrer Webseite mit, was den manüllen Schritt erspart. Wichtig ist dabei, den Hash-Wert stets für die exakte, versionierte Datei-URL zu generieren, denn eine unversionierte URL wie latest.js kann sich jederzeit inhaltlich ändern und würde dann permanent gegen den SRI-Schutz fehlschlagen.

# SRI-Hash lokal aus einer heruntergeladenen Datei generieren
curl -s https://cdn.beispiel-anbieter.de/lib/chart.min.js -o chart.min.js
openssl dgst -sha384 -binary chart.min.js | openssl base64 -A

# Ergebnis in das integrity-Attribut einsetzen:
# integrity="sha384-<generierter-hash>"

4. Die notwendige Kombination mit crossorigin

Damit der Browser die Integritätsprüfung überhaupt durchführen kann, muss die Ressource per Cross-Origin Resource Sharing (CORS) korrekt ausgeliefert werden, was das crossorigin-Attribut im Skript-Tag voraussetzt. Ohne dieses Attribut behandelt der Browser die Anfrage als sogenannte No-CORS-Anfrage, bei der die Antwort als undurchsichtig gilt und der Hash-Vergleich technisch gar nicht möglich ist, weshalb SRI in diesem Fall komplett ignoriert wird, oft ohne sichtbare Fehlermeldung.

Der Wert crossorigin="anonymous" ist für die meisten CDN-Einbindungen die richtige Wahl, da er die Anfrage ohne Zugangsdaten wie Cookies sendet. Der Anbieter-Server muss im Gegenzug den Header Access-Control-Allow-Origin korrekt setzen, was bei etablierten CDN-Anbietern standardmässig der Fall ist, bei selbst betriebenen internen CDN-Lösungen aber explizit konfiguriert werden muss.

5. SRI gilt nicht nur für Skripte: Stylesheets und Fonts absichern

Subresource Integrity ist nicht auf script-Tags beschränkt, sondern funktioniert genauso für link-Tags, über die externe Stylesheets eingebunden werden. Ein manipuliertes CSS-Stylesheet mag auf den ersten Blick harmlos wirken, kann aber über CSS-Injection-Techniken wie das Auslesen von Formulardaten per Attribut-Selektoren oder das visülle Überlagern echter Inhalte mit gefälschten Login-Formularen durchaus sicherheitsrelevant sein.

Auch bei Webfonts, die von einem externen Anbieter geladen werden, lässt sich das integrity-Attribut zusammen mit crossorigin auf dem einbindenden link-Tag setzen. In der Praxis lohnt sich SRI besonders für Stylesheets und Fonts, die von weniger etablierten oder seltener aktualisierten CDN-Anbietern stammen, während große, gut gewartete Font-Dienste ein geringeres Restrisiko darstellen, aber ebenfalls problemlos abgesichert werden können.

6. Grenzen: SRI schützt nicht vor bewusst bösartigem, aber unverändertem Code

Ein zentrales Missverständnis ist die Annahme, SRI würde generell vor bosartigen Drittanbieter-Skripten schützen. Tatsächlich prüft SRI ausschließlich, ob der Inhalt einer Datei mit dem beim Einbinden erwarteten Inhalt übereinstimmt. Ist die Datei bereits zum Zeitpunkt der Hash-Generierung bösartig, etwa weil ein kompromittierter Paket-Anbieter von Anfang an schädlichen Code ausliefert, bestätigt SRI diesen Code lediglich als unverändert, ohne ihn inhaltlich zu bewerten.

SRI schützt außerdem nicht vor Angriffen, die gar nicht über den Dateiinhalt laufen, etwa DNS-Hijacking auf eine komplett andere, vom Angreifer kontrollierte Domain mit eigenem, passendem Hash, oder vor Skripten, die zur Laufzeit dynamisch nachladen und dabei den SRI-geschützten Bereich verlassen. Ein umfassender Schutz kombiniert SRI deshalb stets mit einer restriktiven Content Security Policy, die zusätzlich einschränkt, von welchen Domains überhaupt Skripte nachgeladen werden dürfen.

7. Wartungsaufwand bei Updates der Drittanbieter-Bibliothek

Der praktische Nachteil von SRI liegt im laufenden Wartungsaufwand: Jede inhaltliche Änderung an der eingebundenen Datei, auch ein scheinbar kleines Patch-Update, ändert den Hash-Wert und führt sofort zu einer blockierten Ausführung, sobald das alte integrity-Attribut nicht aktualisiert wird. Teams, die SRI einsetzen, müssen deshalb einen Prozess etablieren, der bei jeder gewollten Versionsaktualisierung automatisch auch den passenden Hash-Wert neu generiert und im Deployment mit ausrollt.

In modernen Build-Pipelines übernehmen Bundler wie Webpack oder Vite diese Aufgabe automatisch für selbst gehostete Assets, sodass der Hash bei jedem Build synchron zur tatsächlichen Datei bleibt. Für extern geladene CDN-Ressourcen bleibt die Verantwortung dagegen beim eigenen Team, weshalb sich ein kleines Skript im CI-Prozess lohnt, das regelmässig prüft, ob eingebundene Hash-Werte noch zu den aktüll ausgelieferten Dateien passen.

8. Praxisempfehlung: Selbst hosten oder gezielt SRI einsetzen

Für Skripte, die sich inhaltlich selten ändern und sicherheitskritische Funktionen wie Zahlungsabwicklung oder Authentifizierung betreffen, ist SRI eine sinnvolle, verhältnismässig einfach umzusetzende Schutzmaßnahme. Für häufig aktualisierte Bibliotheken mit hoher Update-Frequenz lohnt sich dagegen oft die Abwägung, die Datei stattdessen selbst zu hosten und über die eigene Build-Pipeline zu verwalten, wo Integrität ohnehin durch die eigene Versionskontrolle sichergestellt ist.

Als Faustregel gilt: Je kritischer die Funktion des eingebundenen Skripts und je seltener sich dessen Inhalt ändert, desto klarer lohnt sich SRI. Bei volatilen, täglich aktualisierten Analytics- oder Werbe-Skripten dagegen überwiegt der Wartungsaufwand häufig den Sicherheitsgewinn, weshalb hier eine strikte CSP mit begrenzter Domain-Liste oft die praktikablere Alternative darstellt.

9. Fazit: SRI als gezielter Baustein, nicht als Allheilmittel

Subresource Integrity löst ein sehr spezifisches, aber real relevantes Problem: die unbemerkte nachträgliche Manipulation eines bereits eingebundenen Drittanbieter-Skripts. Mit einem einzigen HTML-Attribut, kombiniert mit korrektem CORS-Setup, lässt sich dieses Risiko für sicherheitskritische, selten aktualisierte Skripte wirksam und ohne großen Aufwand absichern.

Wichtig bleibt das realistische Verständnis der Grenzen: SRI prüft Unveränderlichkeit, nicht Vertrauenswürdigkeit des ursprünglichen Inhalts. Ein umfassendes Sicherheitskonzept für Drittanbieter-Skripte kombiniert SRI deshalb immer mit einer restriktiven Content Security Policy und einer bewussten, möglichst kleinen Auswahl an vertrauenswürdigen Drittanbietern.

10. Zusammenfassung

11. FAQ: Subresource Integrity für Drittanbieter-Skripte: Das Wichtigste auf einen Blick