Subresource Integrity (SRI): Fremde Skripte absichern

Kurz: Subresource Integrity lässt den Browser prüfen, ob eine von außen geladene Datei (Skript oder Stylesheet) noch genau die ist, die man erwartet. Wurde sie verändert, lädt der Browser sie nicht.

Das Problem

Wer ein Skript von einem fremden Server (CDN) einbindet, vertraut diesem Server blind. Wird er gehackt oder liefert plötzlich anderen Code, läuft der Schadcode auf deiner Seite mit allen Rechten, siehe XSS (Cross-Site Scripting) und Software-Lieferkette und SBOM.

So funktioniert SRI

Im Tag steht ein Fingerabdruck der Datei, ein Hash etwa mit SHA-256 oder SHA-384:

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

Der Browser lädt die Datei, berechnet den Hash und vergleicht. Stimmt er nicht, wird die Datei blockiert.

Wichtig dabei

• crossorigin="anonymous" ist nötig, damit der Browser die Datei prüfen darf.
• Ändert der Anbieter die Datei legitim (neue Version unter gleicher Adresse), bricht die Seite. Deshalb feste Versionen einbinden, keine „latest”-Adressen.
• SRI ersetzt nicht das Vertrauen in den Anbieter beim ersten Mal: den Hash bildet man aus der geprüften Version.

Besser noch: selbst hosten

Die sicherste Lösung ist, Bibliotheken selbst auszuliefern. Dann gibt es keinen Dritten, der etwas ändern kann, und beim Aufruf wird keine Besucher-IP an ihn gesendet. Das macht auch Emzett so (Wiki-Bibliotheken, Pyodide, sql.js). Ergänzend begrenzt eine Content Security Policy (CSP), von wo überhaupt Skripte geladen werden dürfen.