SRI

SRI (Subresource Integrity) ist eine HTML5-Funktion, mit der Sie den SHA-256/SHA-384/SHA-512-Hash einer externen Ressource festschreiben können. Der Browser berechnet den Hash beim Download und verweigert die Ausführung der Ressource, wenn die Hashes nicht übereinstimmen.

Beispiel: <script src="https://cdn.example/lib.js" integrity="sha384-AbC..." crossorigin="anonymous"></script>

Wovor das schützt: einer CDN-Kompromittierung. Übernimmt ein Angreifer das CDN und liefert verändertes JavaScript aus, verweigert jede Website, die das Skript per SRI einbindet, die Ausführung der veränderten Version. Ohne SRI erhält jede Website still und heimlich die schädliche Nutzlast.

Der Kompromiss: Einen Hash festzuschreiben bedeutet, dass Sie die Ressource nicht aktualisieren können, ohne jede Seite anzupassen, die sie referenziert. Für eigene Assets, die Sie ohnehin bauen, ist SRI eine kostengünstige Absicherung. Für CDN-Skripte von Drittanbietern (jQuery, Analytics-Tags) ist es ein echter Sicherheitsgewinn – zum Preis langsamerer Verbreitung von Updates.

SRI erfordert crossorigin="anonymous" am Tag plus einen CORS-Header in der CDN-Antwort — der Browser muss die Antwort lesen können.

Reale Vorfälle, die SRI gestoppt hätte: Die Magecart-Familie von Kartenskimming-Angriffen kompromittierte wiederholt JavaScript von Drittanbietern, das bei vertrauenswürdigen Anbietern gehostet war (BrowserAloud, Inbenta, Picreel), und schleuste kartenstehlenden Code ein, der auf Tausenden von E-Commerce-Checkout-Seiten geladen wurde. Sowohl der Datendiebstahl bei Ticketmaster 2018 als auch der bei British Airways 2018 betrafen Angreifer, die Skripte auf Hosts veränderten, die die betroffenen Seiten per <script src="…"> einbanden. SRI ist die konkrete Gegenmaßnahme: Hätten diese Seiten den Integritäts-Hash der Skriptversion festgeschrieben, die sie laden wollten, wäre die veränderte Nutzlast an der Prüfung gescheitert und der Browser hätte die Ausführung verweigert.

Wie man SRI-Hashes pragmatisch erzeugt und rotiert: Für eigene Dateien sollte die Build-Pipeline die SRI-Hashes zusammen mit dem Asset-Bundle erzeugen und sie zur Template-Zeit ins HTML einfügen (Next.js, Vite und Webpack unterstützen das alle per Plugin). Für Drittanbieter-Bibliotheken ist der empfohlene Ablauf, sich auf eine bestimmte Version festzulegen, die Datei auf das eigene CDN zu kopieren und diese per SRI festzuschreiben — sich darauf zu verlassen, dass das Upstream-CDN über Monate dieselben Bytes unter derselben URL bereithält, ist riskant. Das integrity-Attribut akzeptiert mehrere durch Leerzeichen getrennte Hashes und ermöglicht so den Übergang von Hash-Algorithmen (liefern Sie SHA-384 und SHA-512 gemeinsam aus; der Browser wählt den, den er unterstützt). Verwandt: CSP, SHA-256. Quelle: W3C — Subresource Integrity.

Durchgerechnetes Beispiel

Sie möchten jQuery 3.7.1 von einem CDN mit SRI-Schutz einbinden. Berechnen Sie den SHA-384-Hash der Datei: openssl dgst -sha384 -binary jquery-3.7.1.min.js | openssl base64 -A gibt etwas wie Bu3qSpvxnAdMaOTsigCcfqUyJYvP7AbsxRRpzqj7M1V2OuoP1bb98c8MQYIPHzxc aus. Binden Sie es ein: <script src="https://code.jquery.com/jquery-3.7.1.min.js" integrity="sha384-Bu3qSpvxnAdMaOTsigCcfqUyJYvP7AbsxRRpzqj7M1V2OuoP1bb98c8MQYIPHzxc" crossorigin="anonymous"></script>. Beim Laden der Seite ruft der Browser die Datei ab, berechnet ihren SHA-384, base64-codiert ihn und vergleicht ihn mit dem integrity-Attribut. Liefert das CDN eine manipulierte Datei — selbst eine Änderung von einem einzigen Byte — weichen die Hashes ab, der Browser blockiert die Ausführung und ein SecurityError erscheint in den DevTools. Die Seite wird trotzdem gerendert; nur das Skript mit fehlgeschlagener Integrität wird unterdrückt.

Wann und warum es zählt

Sobald Ihre Website JavaScript von einer Domain lädt, die Sie nicht kontrollieren, vertrauen Sie den Betreibern dieser Domain, ihrem CDN-Anbieter, ihrem DNS und jedem TLS-Schritt dazwischen. Dieses Vertrauen ist empirisch oft genug fehl am Platz, um relevant zu sein: Supply-Chain-Kompromittierungen von npm-Paketen, jQuery-Plugins, GTM-Containern und Analytics-Skripten trafen große Websites mit einer Rate von mehreren pro Jahr. SRI ist die Absicherung, die kein Vertrauen in den Drittanbieter erfordert. Die pragmatische Einsatzstrategie: Schreiben Sie Drittanbieter-Skripte per SRI fest, die Sie per URL laden (CDN-gehostete Bibliotheken, eingebettete Widgets), aber nicht Skripte, die Sie aus eigener Quelle bündeln und ausliefern, wo Sie die Bytes kontrollieren. Kombinieren Sie es mit CSP require-sri-for script (vorgeschlagen, aber noch nicht breit umgesetzt) oder script-src mit explizit erlaubten Hashes für eine gestaffelte Verteidigung. Quelle: MDN — Subresource Integrity.