Subresource Integrity (SRI)
Subresource Integrity ist ein Sicherheits-Merkmal, bei dem ein eingebundenes Skript oder Stylesheet mit einem Prüf-Hash versehen wird – der Browser führt die Datei nur aus, wenn ihr Inhalt exakt zum Hash passt.
Subresource Integrity sichert eingebundene Fremd-Dateien gegen Manipulation und ergänzt die Content-Security-Policy beim Schutz vor verändertem Drittanbieter-Code.
In einfachen Worten
Bindet eine Website ein Skript oder Stylesheet von einer fremden Quelle ein – etwa über ein Content-Delivery-Network –, vertraut sie darauf, dass diese Datei unverändert ist. Wird die Quelle kompromittiert und die Datei heimlich manipuliert, läuft der fremde Code im Browser jedes Besuchers. Subresource Integrity schließt diese Lücke: Im einbindenden Tag wird ein integrity-Attribut mit dem erwarteten Hash der Datei hinterlegt. Der Browser berechnet beim Laden den Hash der tatsächlich empfangenen Datei und vergleicht ihn – stimmt er nicht überein, wird die Datei verworfen und nicht ausgeführt. So ist sichergestellt, dass genau der geprüfte Code läuft und keine nachträglich veränderte Fassung. Subresource Integrity ergänzt die Content-Security-Policy: Während die Policy regelt, von wo geladen werden darf, stellt sie sicher, dass das Geladene auch unverändert ist.
Wozu brauche ich das?
Sinnvoll überall dort, wo Skripte oder Stile von fremden Quellen eingebunden werden, die man nicht selbst kontrolliert – ausgelagerte Bibliotheken, von einem CDN bezogene Dateien. Bei selbst gehosteten Dateien aus der eigenen Auslieferung ist der Nutzen geringer, weil die Quelle ohnehin unter eigener Kontrolle steht.
Beispiel aus der Praxis
Eine Website bindet eine verbreitete Programm-Bibliothek von einem öffentlichen Content-Delivery-Network ein. Wird dieses Netz angegriffen und die Bibliotheks-Datei manipuliert, würde der Schad-Code auf allen Seiten ausgeführt, die sie einbinden. Mit einem integrity-Hash im Einbindungs-Tag bemerkt der Browser die Abweichung sofort, verwirft die manipulierte Datei und führt sie nicht aus – der Angriff läuft ins Leere, ohne dass der Betreiber eingreifen muss. Eine Auslieferung über HTTPS allein verhindert das nicht, da die Datei dann verschlüsselt, aber bereits manipuliert übertragen wird.
Wirtschaftlicher Nutzen
Subresource Integrity schützt vor einer Angriffsart, die der Betreiber selbst kaum bemerken würde – der heimlichen Manipulation einer eingebundenen Fremd-Datei. Der Aufwand beschränkt sich auf das einmalige Hinterlegen der Hashes, die sich automatisiert erzeugen lassen. Der Wert liegt darin, die Abhängigkeit von der Sicherheit fremder Quellen zu entschärfen, ohne auf deren Vorteile – etwa die schnelle Auslieferung über ein CDN – verzichten zu müssen. Die Hashes lassen sich automatisiert beim Deployment der Seite erzeugen.
Typische Fehler
- Fremde Skripte ohne integrity-Attribut einbinden und blind auf die Unversehrtheit der Quelle vertrauen.
- Den Hash setzen, aber bei einer Aktualisierung der Datei vergessen, ihn anzupassen – die Datei wird dann verworfen.
- Subresource Integrity bei Dateien einsetzen, die sich häufig und unangekündigt ändern – das führt zu plötzlichen Ausfällen.
- Subresource Integrity als Ersatz für eine Content-Security-Policy verstehen – beide decken unterschiedliche Aspekte ab.
Worauf achten?
- Für eingebundene Fremd-Dateien grundsätzlich einen integrity-Hash hinterlegen.
- Den Hash bei jeder Aktualisierung der Datei mit erneuern – am besten automatisiert beim Bauen der Seite.
- Subresource Integrity mit der Content-Security-Policy kombinieren, nicht als Ersatz behandeln.
- Bei Dateien mit häufigen Änderungen abwägen, ob eine feste Version mit festem Hash sinnvoller ist.
Häufig gestellte Fragen
Was ist Subresource Integrity?
Ein Sicherheits-Merkmal, bei dem ein eingebundenes Skript oder Stylesheet mit einem Prüf-Hash versehen wird. Der Browser führt die Datei nur aus, wenn ihr Inhalt exakt zum hinterlegten Hash passt – andernfalls verwirft er sie.
Wovor schützt SRI?
Vor der heimlichen Manipulation eingebundener Fremd-Dateien, etwa wenn ein Content-Delivery-Network kompromittiert wird. Stimmt der Hash der geladenen Datei nicht, wird sie nicht ausgeführt – der manipulierte Code läuft nicht.
Was ist der Unterschied zu einer Content-Security-Policy?
Die Content-Security-Policy regelt, von welchen Quellen geladen werden darf. Subresource Integrity stellt sicher, dass das Geladene unverändert ist. Beide ergänzen sich und decken unterschiedliche Aspekte des Schutzes vor Drittanbieter-Code ab.
Was passiert bei einer Aktualisierung der Datei?
Ändert sich die Datei, ändert sich auch ihr Hash – das integrity-Attribut muss dann angepasst werden, sonst verwirft der Browser die neue Fassung. Am besten erzeugt man die Hashes automatisiert beim Bauen der Seite.