Subresource Integrity für Skripte und Stylesheets von Drittanbietern

Worum es geht

MDN (zitiert) beschreibt Subresource Integrity als Schutz gegen einen kompromittierten Drittanbieter-Host: Das integrity-Attribut enthält einen oder mehrere Hashes, jeweils mit dem Präfix sha256-, sha384- oder sha512-, und bevor der Browser ein Skript ausführt oder ein Stylesheet anwendet, hasht er den abgerufenen Inhalt und vergleicht. Er verwendet nur den stärksten vorhandenen Algorithmus, akzeptiert eine Übereinstimmung mit irgendeinem gelisteten Wert dieses Algorithmus und verweigert die Ressource bei Nichtübereinstimmung mit einem Netzwerkfehler. Es gilt für <script> sowie für <link> mit rel gleich stylesheet, preload oder modulepreload. Die W3C-Spezifikation (zitiert) hält fest, dass Subresource Integrity CORS voraussetzt: Eine Cross-Origin-Ressource muss mit dem crossorigin-Attribut angefragt werden, und der Server muss mit Access-Control-Allow-Origin antworten, sonst kann die Prüfung nicht durchgeführt werden.

Warum es wichtig ist

Eine Seite, die https://cdn.example/lib.js lädt, führt aus, was dieser Host ausliefert – heute und auch dann, wenn der Host kompromittiert, verkauft oder per DNS gekapert wird. Ein Hash macht aus "dem Host vertrauen" ein "dieser exakten Datei vertrauen", dieselbe Disziplin wie das Anpinnen einer Abhängigkeit per Digest.

So wird es angewendet

• Den Hash aus genau den geprüften Bytes berechnen: cat lib.js | openssl dgst -sha384 -binary | openssl base64 -A (nach MDN), oder den vom Bundler ausgegebenen Wert übernehmen.
• Nur versionierte URLs anpinnen (/lib@1.2.3/lib.min.js); eine "latest"-URL schlägt fehl, sobald der Anbieter sie aktualisiert – genau das ist die Funktionsweise.
• crossorigin="anonymous" an jedem Cross-Origin-Element mit integrity ergänzen; ohne dieses Attribut lädt der Browser die Ressource überhaupt nicht.
• Eine Hash-Aktualisierung wie ein Abhängigkeits-Update behandeln: neue Datei abrufen, Diff oder Changelog prüfen, neu berechnen, committen.
• Den Fehler-Tracker auf fehlgeschlagenes Laden der angepinnten Ressource beobachten (ein Skript, das sein globales Objekt nie definiert); eine plötzliche Häufung bedeutet, dass der Anbieter die Datei geändert hat oder jemand sie manipuliert hat.
• Mit einer Content Security Policy kombinieren, die Skriptquellen einschränkt; SRI prüft den Inhalt, CSP prüft die Herkunft.

Stolpersteine

Ressourcen, die sich legitim pro Anfrage unterscheiden (Tag-Manager, A/B-Skripte, personalisierte Bundles), lassen sich nicht anpinnen; entweder eine feste Kopie selbst hosten oder das Vertrauen akzeptieren. Eine minifizierte Datei hashen, nachdem eine Pipeline sie erneut minifiziert. Vergessen, dass ein Skript, das das angepinnte Skript zur Laufzeit nachlädt, nicht erfasst ist. Ein CDN ohne CORS-Header, wodurch jedes angepinnte Laden fehlschlägt.