Subresource Integrity (SRI): Schutz gegen Supply-Chain-Angriffe
Wenn ein CDN kompromittiert wird, schützt SRI Ihre Website automatisch. Der Browser prüft einen kryptografischen Hash — stimmt er nicht, wird das Script blockiert.
Warum Subresource Integrity unverzichtbar ist
Subresource Integrity (SRI) schützt Ihre Website vor Supply-Chain-Angriffen über kompromittierte CDNs. Moderne Websites laden Scripts und Stylesheets von externen CDNs — jQuery, Bootstrap, Google Analytics. Das spart Bandbreite und verbessert die Ladezeit. Aber es schafft einen blinden Vertrauenspunkt: Wird das CDN kompromittiert, führt Ihre Website schadhaften Code aus — ohne es zu merken. Der Wolf-Agents Web Security Check prüft SRI als Teil der 166 Prüfpunkte und bewertet die korrekte Implementierung mit bis zu 15 Punkten.
Subresource Integrity (SRI) löst dieses Problem. Sie geben im HTML einen kryptografischen Hash der erwarteten Datei an. Der Browser lädt die Datei, berechnet den Hash und vergleicht. Stimmt er nicht überein, wird die Ressource blockiert — der Angriff scheitert.
Wie SRI funktioniert
SRI basiert auf einem einfachen Prinzip: Sie berechnen vorab einen kryptografischen Hash der Datei und speichern ihn im HTML. Der Browser berechnet denselben Hash nach dem Download und vergleicht.
Hash berechnen
Sie laden die Datei herunter und berechnen den SHA-384-Hash. Diesen fügen Sie als integrity-Attribut in Ihr HTML ein.
Browser lädt die Datei
Der Browser lädt das Script vom CDN und berechnet ebenfalls den Hash der empfangenen Datei.
Hash-Vergleich
Stimmen die Hashes überein, wird das Script ausgeführt. Stimmen sie nicht überein — z.B. weil das CDN kompromittiert wurde — blockiert der Browser die Ausführung.
<!-- OHNE SRI: Blindes Vertrauen in das CDN -->
<script src="https://cdn.example.com/jquery-3.6.0.min.js"></script>
<!-- MIT SRI: Browser prüft den Hash vor der Ausführung -->
<script
src="https://cdn.example.com/jquery-3.6.0.min.js"
integrity="sha384-vtXRMe3mGCbOeY7..."
crossorigin="anonymous">
</script>Hash-Algorithmen
| Algorithmus | Präfix | Sicherheit | Empfehlung |
|---|---|---|---|
| SHA-256 | sha256- | Gut | Minimum |
| SHA-384 | sha384- | Sehr gut | Empfohlen |
| SHA-512 | sha512- | Ausgezeichnet | Höchste Sicherheit |
SRI-Hashes generieren
Drei Wege zum Hash: per Kommandozeile (schnell, für einzelne Dateien), über Build-Tools (automatisch, für Projekte) oder mit dem Online-Generator srihash.org. Für Produktions-Builds ist die automatische Generierung per Webpack oder Vite empfohlen.
# Methode 1: openssl (empfohlen)
curl -s https://cdn.example.com/script.js | \
openssl dgst -sha384 -binary | openssl base64 -A
# Methode 2: shasum
curl -s https://cdn.example.com/script.js | \
shasum -b -a 384 | awk '{ print $1 }' | xxd -r -p | base64
# Ergebnis: sha384-vtXRMe3mGCbOeY7l30aIg8H9p3GdeSe4IFlP6...Kommandozeile
Schnell für einzelne Dateien. openssl dgst -sha384 ist auf den meisten Systemen vorinstalliert.
Build-Tools
Webpack (webpack-subresource-integrity) und Vite (vite-plugin-sri) generieren Hashes automatisch für alle Assets.
Online-Generator
srihash.org — URL eingeben, fertigen Tag mit Hash erhalten. Ideal für schnelle Tests.
SchnelltestsWelche Ressourcen brauchen SRI?
SRI funktioniert nur für <script> und <link rel="stylesheet"> — nicht für Bilder, Videos oder iFrames. Die wichtigste Regel: Jede externe Ressource von einem CDN braucht SRI.
SRI erforderlich
- Externe CDN-Scripts (jQuery, Bootstrap)
- Externe CDN-Stylesheets
- Analytics-Scripts (empfohlen)
- Third-Party-Widgets (wenn möglich)
SRI nicht möglich / nötig
- Eigene Scripts (same-origin)
- Dynamisch generierte Inhalte
- Ressourcen ohne CORS-Header
- Bilder, Videos, iFrames
Für hochsensible Anwendungen (Payment, Gesundheitsdaten) bietet SRI auch für self-hosted Scripts Schutz gegen Server-Kompromittierung — genau dieses Szenario zeigt der British-Airways-Vorfall, bei dem ein eigenes Script (modernizr.js) auf dem BA-Server manipuliert wurde.
SRI richtig einsetzen
SRI ist nur so stark wie Ihre Implementierung. Drei Regeln machen den Unterschied: versionierte URLs, ein Fallback-Mechanismus und automatische Hash-Generierung im Build-Prozess.
1. Versionierte URLs verwenden
Laden Sie nie jquery-latest.min.js — verwenden Sie immer die explizite Version (jquery-3.6.0.min.js). Bei unversionierten URLs kann das CDN die Datei jederzeit ändern und Ihr Hash bricht.
2. crossorigin="anonymous" immer setzen
Ohne dieses Attribut kann der Browser den Dateiinhalt nicht lesen und den Hash nicht prüfen. Vergessen Sie crossorigin, ist SRI wirkungslos.
3. Fallback bei SRI-Fehler
Ein onerror-Handler lädt eine lokale Kopie, wenn das CDN-Script blockiert wird — so bleibt Ihre Website funktionsfähig, auch wenn das CDN kompromittiert ist.
<!-- SRI mit Fallback auf lokale Kopie -->
<script
src="https://cdn.example.com/jquery.min.js"
integrity="sha384-..."
crossorigin="anonymous"
onerror="loadLocalFallback()">
</script>
<script>
function loadLocalFallback() {
const script = document.createElement('script');
script.src = '/local/jquery.min.js';
document.head.appendChild(script);
}
</script>SRI mit Import Maps und ES Modules
Klassisches SRI schützt nur die direkt im HTML referenzierte Datei — nicht deren Imports. Import Maps mit integrity-Feld lösen dieses Problem: Jedes Modul, auch dynamisch importierte und transitive Dependencies, kann individuell per Hash abgesichert werden. Seit April 2025 Baseline Newly Available (Chrome 127+, Safari 18+, Firefox 138+).
<!-- Import Maps mit integrity-Feld (Baseline Newly Available, April 2025) -->
<script type="importmap">
{
"imports": {
"lodash": "https://cdn.example.com/lodash@4.17.21/lodash.min.js"
},
"integrity": {
"https://cdn.example.com/lodash@4.17.21/lodash.min.js": "sha384-HASH"
}
}
</script>
<!-- Browser prüft den Hash automatisch beim Import -->
<script type="module">
import _ from 'lodash';
</script>Vorteile gegenüber klassischem SRI
import() wird über die Import Map automatisch mit Hash-Prüfung versehen.
Jedes Modul — auch tief verschachtelte Sub-Dependencies — kann individuell abgesichert werden.
Alle Hashes an einer Stelle statt verteilt über HTML-Tags.
SRI und regulatorische Anforderungen
SRI ist nicht nur technisch sinnvoll — PCI DSS 4.0.1 macht Script-Integrität seit März 2025 zur Pflicht für alle Unternehmen, die Kreditkartendaten verarbeiten.
PCI DSS 4.0.1 Req. 6.4.3
Seit 31. März 2025 verpflichtend: Alle Scripts auf Zahlungsseiten müssen autorisiert, inventarisiert und auf Integrität geprüft werden. SRI erfüllt die Integritätsprüfung direkt.
NIS2 Art. 21 lit. e / BSI APP.3.1
NIS2 Art. 21 Abs. 2 lit. e fordert Sicherheit bei Erwerb, Entwicklung und Wartung von Systemen — einschließlich des Umgangs mit Schwachstellen. SRI ist ein technisch prüfbarer Nachweis für die Integrität externer Ressourcen. BSI IT-Grundschutz APP.3.1 empfiehlt Maßnahmen gegen Supply-Chain-Angriffe. Im deutschen §30 Abs. 2 Nr. 5 BSIG (NIS2UmsuCG) ist dies seit 06.12.2025 konkretisiert.
OWASP Top 10:2025 #3
Software Supply Chain Failures ist Platz 3 der OWASP Top 10:2025. SRI ist die primäre Browser-seitige Gegenmaßnahme gegen kompromittierte Third-Party-Scripts.
Wie steht Ihre Domain bei Subresource Integrity?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.
Häufig gestellte Fragen
Was ist Subresource Integrity (SRI)?
Subresource Integrity ist ein Sicherheitsmechanismus, der es dem Browser ermöglicht zu prüfen, ob eine externe Ressource (Script oder Stylesheet) manipuliert wurde. Sie geben einen kryptografischen Hash im integrity-Attribut an — stimmt der Hash der geladenen Datei nicht überein, blockiert der Browser die Ausführung.
Warum brauche ich das crossorigin-Attribut bei SRI?
Ohne crossorigin="anonymous" hat der Browser bei Cross-Origin-Ressourcen keinen Zugriff auf den Inhalt der Datei und kann den Hash nicht prüfen. Das Attribut aktiviert CORS (Cross-Origin Resource Sharing), damit der Browser den Dateiinhalt lesen und den Hash berechnen kann.
Welchen Hash-Algorithmus soll ich für SRI verwenden?
SHA-384 ist die empfohlene Wahl — es bietet ein gutes Gleichgewicht aus Sicherheit und Performance. SHA-256 ist das Minimum, SHA-512 bietet maximale Sicherheit. Verwenden Sie einheitlich denselben Algorithmus für alle Hashes im integrity-Attribut.
Schützt SRI gegen den Polyfill.io-Angriff?
Teilweise. Websites, die polyfill.io mit integrity-Attribut eingebunden hatten, waren automatisch geschützt — der Browser blockierte das manipulierte Script. Allerdings generierte Polyfill.io Antworten dynamisch je nach User-Agent, was die Wirksamkeit von SRI einschränkte, da der Hash nur für eine bestimmte Response galt.
Für welche HTML-Elemente funktioniert SRI?
SRI funktioniert ausschließlich für script- und link-Tags (Stylesheets). Für Bilder, Videos, iFrames oder andere Ressourcen gibt es keine SRI-Unterstützung — das integrity-Attribut wird vom Browser ignoriert.
Was passiert, wenn sich eine CDN-Datei ändert?
Der Browser blockiert die Ressource, weil der gespeicherte Hash nicht mehr zur geänderten Datei passt. Lösung: Verwenden Sie versionierte URLs (z.B. jquery-3.6.0.min.js statt jquery-latest.min.js), damit sich die Datei nicht ohne Ihr Wissen ändert. Bei geplanten Updates generieren Sie den neuen Hash vorab.
Kann ich SRI automatisch in meinem Build-Prozess generieren?
Ja. Webpack (webpack-subresource-integrity Plugin), Vite (vite-plugin-sri) und andere Build-Tools können SRI-Hashes automatisch für alle generierten Assets einfügen. Das ist die empfohlene Methode für Produktions-Builds, da manuelle Hash-Pflege fehleranfällig ist.