Subresource Integrity: Erwartete Dateien verlässlich wiedererkennen

Welches Vertrauen SRI begrenzt

HTTPS sichert den Transport zum angesprochenen Server. Es verhindert nicht, dass dieser Server selbst eine veränderte Datei liefert. SRI kann diese Änderung erkennen, wenn der erwartete Hash in Ihrem HTML beziehungsweise in der zuständigen Integritätskonfiguration unverändert bleibt. Kann ein Angreifer auch diese Metadaten austauschen, ist die Kontrolle an dieser Stelle unterlaufen.

Besonders gut eignet sich SRI für geprüfte, versionierte statische Dateien. Same-Origin-Dateien können ebenfalls geprüft werden; hier müssen Sie betrachten, ob Datei und Metadaten überhaupt getrennte Vertrauensgrenzen haben. Gegen eine kompromittierte Abhängigkeit, die bereits vor der Hashbildung im Build liegt, schützt der anschließende Vergleich nicht. W3C SRI: Ziele und Sicherheitsgrenzen

Der Web Security Check untersucht begrenzt das statische HTML der finalen Antwort: erkennbare externe Scripts/Stylesheets, Integritätsmetadaten und CORS-Lademodus. Er lädt die Dateien nicht zum Hashvergleich und führt keine vollständige dynamische Ressourceninventur durch. „Metadaten vorhanden“ ist deshalb kein bestätigter Inhaltsvergleich.

Von geprüften Bytes zum Browservergleich

Der Ablauf hat drei Schritte: Sie legen eine geprüfte Datei fest und erzeugen ihren Hash. Der Browser lädt die referenzierte Ressource. Er vergleicht deren Inhalt anhand der gültigen Metadaten; bei Abweichung wird die Ressource nicht verwendet. Bei Übereinstimmung müssen weitere Voraussetzungen wie CSP, MIME-Typ und CORS trotzdem passen.

Mehrere unterstützte Algorithmen bedeuten nicht „irgendeiner reicht“: Der stärkste vorhandene unterstützte Algorithmus entscheidet. Mehrere Hashes desselben stärksten Algorithmus können alternative Inhalte erlauben. Unbekannte Algorithmen werden ignoriert; wenn keine erkannten Metadaten bleiben, entsteht daraus keine Integritätskontrolle. Ein bloß vorhandenes Attribut ist daher kein ausreichender Nachweis. SRI §§ 3.2–3.3

Einen Hash aus der geprüften Datei erzeugen

Erzeugen Sie den Hash aus genau dem freigegebenen Artefakt, das später ausgeliefert wird. Blindes Hashen der gerade heruntergeladenen Drittanbieterantwort würde auch eine bereits manipulierte Version festschreiben. Bei einer bewussten Aktualisierung gehören Quellenherkunft, Versionsprüfung und Funktionstest deshalb vor die Freigabe.

Das folgende vollständige Beispiel verwendet ausschließlich eine synthetische lokale Datei. Die erste Zeile erzeugt sri-demo.js im aktuellen Arbeitsverzeichnis; verwenden Sie dafür einen leeren Testordner:

printf 'window.sriLoaded = true;\n' > sri-demo.js
openssl dgst -sha384 -binary sri-demo.js | openssl base64 -A

Mit genau diesen Bytes einschließlich Zeilenumbruch lautet das Integritätsattribut:

<script src="/assets/sri-demo.js"
  integrity="sha384-V7pNkAZ7iDlrSXBjbzvgfRGvaRgOebq8zZnoQerOZvWviUZKtNamq8+edcPrWG67"></script>

Die URL muss diese Datei tatsächlich liefern; das Beispiel installiert keine Ressource. Für ein klassisches Skript von einem anderen Origin kommt üblicherweise crossorigin="anonymous" hinzu. Der fremde Server muss einen passenden CORS-Zugriff erlauben. Bei öffentlicher anonymer Auslieferung kann das Access-Control-Allow-Origin: * sein. Modulskripte verwenden bereits den CORS-Modus; ein dort fehlendes crossorigin-Attribut allein ist kein Fehler.

Ein Build kann Hashes und Verweise gemeinsam erzeugen. Ob ein konkretes Plugin auch nachgeladene Chunks, Styles, Preloads und Modulabhängigkeiten erfasst, muss am erzeugten Ergebnis geprüft werden. Es gibt keine universelle Zusage „alle Assets automatisch“. Onlinegeneratoren sind für dieses Verfahren nicht nötig und ersetzen keine Prüfung der Eingangsdaten.

Welche Ressourcen und Änderungen erfasst werden

SRI ist kein allgemeines integrity-Attribut für jedes HTML-Element. Typische Anwendungsfälle sind externe Skripte und Stylesheet-Links; HTML definiert zusätzlich passende Ladewege wie Preloads, und Fetch besitzt eine Integritätsoption. Bilder, Videos und iframe-Dokumente werden nicht dadurch geprüft, dass Sie ihnen ein beliebiges integrity-Attribut hinzufügen. SRI §§ 3.4–3.6

Dynamische Antworten machen den Vergleich nicht unwirksam: Abweichende Bytes scheitern weiterhin. Sie erschweren aber die Pflege aller beabsichtigten Varianten. Das betrifft etwa personalisierte Widgets, automatisch wechselnde Analytics-Skripte oder Antworten abhängig von Browser und Region. Wählen Sie dann einen stabilen freigegebenen Endpunkt, eine zulässige selbst verwaltete Version oder eine andere überprüfte Integrationsstrategie. Entfernen Sie einen Dienst, wenn sein verbleibendes Vertrauen nicht zu Ihrem Bedarf passt.

Auch bei eigenen Skripten kann SRI eine zusätzliche Grenze bilden, sofern der Angreifer nicht zugleich die Metadaten ändern kann. Eine pauschale Ausnahme für alle Same-Origin-Dateien wäre daher ebenso falsch wie das Versprechen, SRI sichere eine vollständige Serverkompromittierung ab.

Updates, Fehler und Rückweg

Verwenden Sie stabile Versions- oder Inhaltsadressen. Veröffentlichen Sie neue Dateien vor den HTML-/Import-Map-Verweisen und erhalten Sie alte Artefakte so lange, wie zwischengespeicherte Dokumente sie noch referenzieren. Hash, Version und Datei gehören in denselben Freigabeprozess; Cache-Control beeinflusst den Übergang.

Prüfen Sie mindestens die erwartete Datei, eine lokal veränderte Variante und den Ausfall der CORS-Freigabe. Der gute Fall muss funktionieren, der manipulierte darf nicht ausgeführt werden. Ein Ressourcenfehler ist dabei noch keine eindeutige Diagnose: Netzwerk, MIME, CORS, CSP und SRI können alle die Verwendung verhindern. Browserkonsole und Netzwerkantwort helfen, die Ursache einzugrenzen.

Ein Fallback kann eine separat vertrauenswürdige lokale Kopie derselben freigegebenen Version laden. Er darf nach einem SRI-Fehler nicht dieselbe fremde Datei ohne Prüfung erneut einbinden. Ein error-Handler muss außerdem bereits registriert sein, bevor das Ladeereignis scheitert; inline-Handler können an Ihrer CSP scheitern. Deshalb gehört ein Fallback in den getesteten Anwendungscode, nicht als ungeprüftes universelles Copy-and-paste-Muster in jede Seite.

Bei unerwarteter Blockierung wechseln Sie auf das vorherige bekannte Paar aus Datei und Metadaten oder nehmen die betroffene Funktion kontrolliert außer Betrieb. Prüfsummen zu entfernen, ohne die gelieferte Änderung zu verstehen, beseitigt die vorgesehene Kontrolle. Eine erneute Hashbildung allein ist keine Ursachenprüfung.

Modulabhängigkeiten einzeln absichern

Der Hash eines Einstiegsmoduls wird nicht automatisch auf seine Imports übertragen. Eine Import Map kann pro Modul-URL eigene Integritätsmetadaten hinterlegen. Die Einträge müssen rechtzeitig vor dem betroffenen Laden bereitstehen und alle gewünschten direkten, transitiven und dynamischen Imports ausdrücklich erfassen. Ein einziger Eintrag erfasst keinen gesamten Abhängigkeitsbaum. HTML: Import-Map-Verarbeitung

Dieses Schema ist absichtlich nicht ausführbar: Ersetzen Sie jeden beschreibenden Hashplatzhalter durch den Digest der jeweiligen geprüften Datei.

<script type="importmap">
{
  "imports": { "bibliothek": "/assets/bibliothek.v1.js" },
  "integrity": {
    "/assets/bibliothek.v1.js": "sha384-DIGEST_DER_BIBLIOTHEK",
    "/assets/helfer.v1.js": "sha384-DIGEST_DES_HELFERS"
  }
}
</script>

Die am 27.09.2026 gelesenen Implementierungsdaten führen das integrity-Feld ab Chrome 127, Safari 18 und Firefox 138. Das ist von der früheren Unterstützung einfacher Import Maps zu unterscheiden. Die lokale Chromium-147-Probe zeigte sowohl einen ungeprüft nachgeladenen geänderten Kindimport als auch dessen Blockierung mit eigenem Integritätseintrag. Andere Zielbrowser und Ihr Build bleiben gesondert zu prüfen.

Eine dokumentweite Pflicht zu Integritätsmetadaten über Integrity-Policy ist ein neuerer Mechanismus mit eigenem Unterstützungsstand. Sie ist nicht mit dem etablierten Einzelressourcenvergleich gleichzusetzen; siehe zusätzliche Header.

Integrität ist nur ein Teil der Lieferkettensicherheit

SRI bestätigt weder die Autorisierung eines Skripts noch dessen geschäftliche Notwendigkeit, Sicherheit oder vollständige Erfassung. Für Zahlungsseiten ist deshalb zwischen technischer Integritätskontrolle und dem anwendbaren PCI-DSS-Prüfumfang zu unterscheiden. Schon die PCI-SSC-Auskunft zu 3DS-Skripten enthält besondere Geltungsbedingungen; sie ist keine allgemeine Ausnahme für beliebige Zahlungsskripte.

Ein SRI-Fund ergibt ebenso wenig einen NIS2-Nachweis. Inventar, sichere Bezugsquellen, Updatepflege, geschützte Builds und das Verhalten zugelassenen Codes bleiben eigene Aufgaben. Compliance-Übersicht