Subresource Integrity (SRI): Skripte absichern 2026

Was Subresource Integrity ist und warum es 2026 zählt

Subresource Integrity ist ein W3C-Standard, der es Browsern erlaubt, die Integrität extern geladener Ressourcen zu überprüfen. Sie hinterlegen dazu im <script>- oder <link>-Tag ein integrity-Attribut mit einem kryptografischen Hash des erwarteten Dateiinhalts. Bevor der Browser das Skript ausführt oder das Stylesheet anwendet, berechnet er den Hash der heruntergeladenen Datei und vergleicht ihn mit dem hinterlegten Wert. Stimmen beide überein, wird die Ressource ausgeführt — andernfalls verwirft der Browser sie und meldet einen Fehler (MDN).

Die Relevanz ergibt sich aus der Realität moderner Websites: 92 % aller Seiten laden mindestens eine Drittanbieter-Ressource (HTTP Archive Web Almanac 2024), und die mediane Seite fordert 20 externe Skripte mit rund 449 KB an (HTTP Archive Web Almanac 2024). Skripte machen 30,5 % aller Drittanbieter-Anfragen nach Inhaltstyp aus (HTTP Archive Web Almanac 2024). Jedes dieser Skripte ist ein potenzielles Einfallstor: Wird der Server eines Anbieters kompromittiert oder die Datei unterwegs verändert, läuft fremder Code mit allen Rechten in Ihrem Seitenkontext.

SRI adressiert eine sehr konkrete Bedrohungsklasse: Supply-Chain-Angriffe über kompromittierte oder ausgetauschte Skripte. Die ENISA ordnet klassische Software-Supply-Chain-Angriffe als eine der zehn häufigsten Bedrohungskategorien ein — sie machten 10,6 % der analysierten Vorfälle aus (ENISA Threat Landscape 2025, 4.875 untersuchte Vorfälle). Genau dort setzt SRI an: Es schützt nicht vor einem geknackten CDN-Konto, aber es verhindert, dass der dort manipulierte Code in Ihren Besucher-Browsern Schaden anrichtet.

Wie ein SRI-Hash technisch funktioniert

Ein SRI-Hash ist ein Base64-kodierter kryptografischer Fingerabdruck des Dateiinhalts, dem ein Algorithmus-Präfix vorangestellt ist. Der Browser lädt die Ressource, berechnet den Hash "on the fly" und bricht die Ausführung ab, sobald der Wert abweicht (MDN). Erlaubt sind die Präfixe sha256, sha384 und sha512 — konforme Browser müssen alle drei unterstützen (W3C SRI). Empfohlen wird in der Praxis sha384 als ausgewogener Kompromiss zwischen Sicherheit und Performance.

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

<link
  rel="stylesheet"
  href="https://cdn.example.com/style.css"
  integrity="sha384-9ndCyUa8q2y2bI3rvT2gI3lyf3v6dGmF"
  crossorigin="anonymous">

Sie können mehrere Hashes — etwa für verschiedene Algorithmen — durch Leerzeichen getrennt angeben. Der Browser nutzt den stärksten von ihm unterstützten. Das erlaubt eine sanfte Migration von schwächeren zu stärkeren Hash-Funktionen, ohne ältere Clients auszusperren. Wichtig: SRI schützt statische, unveränderliche Dateien. Bei Ressourcen, die sich serverseitig dynamisch ändern, müsste der Hash bei jeder Änderung neu generiert werden — hier ist SRI ungeeignet.

Supply-Chain-Angriffe: Die Bedrohung, die SRI adressiert

Web-Skimming — auch als Magecart bekannt — ist die prominenteste Angriffsform, gegen die SRI hilft. Angreifer injizieren JavaScript in Bezahl- oder Formularseiten, um Kreditkarten- und Zugangsdaten direkt im Browser abzugreifen. Laut einer RiskIQ-Auswertung wird alle 16 Minuten ein Magecart-Angriff versucht (RiskIQ). Die Bedrohung wächst: Recorded Future verzeichnete einen Anstieg von 103 % innerhalb von sechs Monaten im Zeitraum 2024/2025 (Recorded Future).

Das Tückische an dieser Angriffsklasse: Sie umgeht klassische serverseitige Schutzmaßnahmen vollständig. Eine Web Application Firewall, ein gehärteter Server und regelmäßige Backups helfen nicht, wenn der Schadcode legitim über ein eingebundenes Drittanbieter-Skript ausgeliefert wird und ausschließlich im Browser des Besuchers ausgeführt wird. Der Server des Shopbetreibers "sieht" diesen Code nicht — er steht im Quelltext einer Datei auf einem fremden CDN. Genau diese Lücke schließt eine clientseitige Integritätsprüfung: SRI verlagert die Kontrolle dorthin, wo der Code tatsächlich ausgeführt wird. Vor dem Hintergrund, dass Skimming-Kampagnen wie CosmicSting zeitweise 5 bis 30 Shops pro Stunde trafen (Sansec), ist diese Verlagerung kein theoretischer Luxus, sondern eine praktische Notwendigkeit für jeden Betreiber, der fremde Skripte einbindet.

Die wirtschaftliche Dimension ist erheblich: Die durchschnittlichen Kosten eines Datenlecks lagen 2024 bei 4,88 Millionen USD (IBM Cost of a Data Breach 2024). Für einen deutschen Onlineshop bedeutet ein über fremden Code abgegriffener Datensatz nicht nur Reputationsschaden, sondern auch eine mögliche Meldepflicht nach Art. 33 DSGVO.

Die Realität: SRI ist verbreitet, aber kaum genutzt

Die Adoptionszahlen zeichnen ein paradoxes Bild. Einerseits ist SRI auf vielen Seiten präsent: 23,2 % der Desktop-Seiten und 21,3 % der Mobile-Seiten setzen mindestens ein integrity-Attribut ein (HTTP Archive Web Almanac 2024). Andererseits ist die tatsächliche Abdeckung minimal: Der Median liegt bei nur 3,23 % der Skripte pro Seite, die gegen einen Hash geprüft werden — und dieser Wert ist seit 2022 praktisch unverändert (HTTP Archive Web Almanac 2024).

Selbst die Seiten mit der höchsten Abdeckung schützen im 90. Perzentil nur 12,5 % ihrer Skripte per SRI (HTTP Archive Web Almanac 2024). Die meisten geschützten Ressourcen stammen von CDNs — Spitzenreiter sind www.gstatic.com (35 %), cdnjs.cloudflare.com (7 %) und code.jquery.com (5–6 %) (HTTP Archive Web Almanac 2024). Bemerkenswert: Shopify hat SRI zugunsten des integrity-Attributs von Import-Maps aufgegeben (HTTP Archive Web Almanac 2024) — ein Hinweis darauf, dass sich die Schutzmechanik weiterentwickelt.

SRI im Zusammenspiel mit CSP und anderen Headern

SRI ist kein Einzelkämpfer. Die volle Schutzwirkung entfaltet es im Verbund mit weiteren Sicherheitsmechanismen — allen voran der Content Security Policy. Während SRI die Integrität bekannter, erlaubter Skripte sichert, kontrolliert CSP, welche Quellen überhaupt geladen werden dürfen. Beide ergänzen sich, statt sich zu ersetzen.

• CSP require-sri-for-Ansatz: Über CSP lässt sich erzwingen, dass Skripte und Styles nur mit gültigem Integritätshash geladen werden — SRI wird damit von der Empfehlung zur Pflicht.
• script-src mit Nonces: CSP autorisiert legitime Skripte per Einmal-Token, SRI prüft zusätzlich deren Inhalt. Zusammen schließen sie sowohl Injection als auch Manipulation aus.
• Strict-Transport-Security (HSTS): Erzwingt HTTPS und verhindert, dass Skripte unterwegs über eine unverschlüsselte Verbindung ausgetauscht werden.
• Mixed-Content-Vermeidung: Ergänzt SRI, weil Mixed Content eine unverschlüsselte Lieferkette öffnet, in der Manipulation überhaupt erst möglich wird.
• X-Content-Type-Options: Verhindert MIME-Sniffing, sodass eine Ressource nicht entgegen ihrer Deklaration als ausführbares Skript interpretiert wird.

Wer bereits seine HTTP-Security-Header sauber konfiguriert hat, sollte SRI als logischen nächsten Baustein begreifen. Erst die Kombination aus Transport-Sicherheit (HTTPS/HSTS), Quellen-Kontrolle (CSP) und Integritätsprüfung (SRI) bildet ein mehrschichtiges Konzept gegen Skript-basierte Angriffe. Ergänzend lohnt der Blick auf die Vertrauensebene der Zertifikate: Eine kontinuierliche Auswertung der Certificate-Transparency-Logs deckt fälschlich ausgestellte Zertifikate auf, die eine Voraussetzung für unbemerkte Man-in-the-Middle-Manipulation von Skripten sein können.

SRI als Compliance-Baustein: PCI DSS 4.0 und DSGVO

SRI ist längst nicht mehr nur "nice to have". Mit PCI DSS 4.0 wurde die Integritätsprüfung von Skripten auf Bezahlseiten faktisch verbindlich. Anforderung 6.4.3 verlangt ein Inventar aller auf Zahlungsseiten verwendeten Skripte, in dem jede Ressource autorisiert, mit einer Integritätsprüfung versehen und begründet ist (PCI Security Standards Council). Anforderung 11.6.1 ergänzt das um die Pflicht, unerlaubte Änderungen an Headern und Skripten der Bezahlseite zu erkennen und zu melden (PCI Security Standards Council).

Auch im DSGVO-Kontext zahlt SRI ein. Art. 32 DSGVO fordert "geeignete technische und organisatorische Maßnahmen". Verhindert SRI, dass manipulierter Fremdcode personenbezogene Daten exfiltriert, reduziert das nachweisbar das Risiko einer meldepflichtigen Datenpanne. In Kombination mit einer dokumentierten Datenschutz-Folgenabschätzung für Web-Tracking entsteht ein belastbarer Nachweis technischer Schutzvorkehrungen.

SRI-Abdeckung überwachen: Warum einmal setzen nicht reicht

Das größte praktische Problem mit SRI ist nicht die Einrichtung, sondern die Pflege. Ein integrity-Attribut ist nur so gut wie sein Hash — und der gilt für genau eine Dateiversion. Aktualisiert ein CDN-Anbieter seine Bibliothek, ändert ein Build-Prozess die Datei oder wechselt ein Entwickler die Skript-Quelle, passiert eines von zwei Dingen: Entweder bricht das Skript, weil der alte Hash nicht mehr passt, oder das Attribut wird im Eifer des Gefechts ganz entfernt — und der Schutz verschwindet unbemerkt.

Genau hier setzt kontinuierliche Überwachung an. Es gibt zwei Ebenen, die sich ergänzen: Erstens die Erkennung neuer, ungeschützter externer Skripte — also Ressourcen, die ohne integrity-Attribut hinzugekommen sind. Zweitens die Erkennung veränderter Externals, bei denen sich der ausgelieferte Inhalt einer Drittanbieter-Datei gegenüber dem letzten Check verändert hat. Beides sind Frühwarnsignale für eine potenziell kompromittierte Lieferkette.

Die Stagnation der SRI-Abdeckung — seit 2022 unverändert bei rund 3,23 % der Skripte pro Seite (HTTP Archive Web Almanac 2024) — zeigt, dass manuelle Pflege in der Praxis selten dauerhaft durchgehalten wird. Der Grund ist menschlich nachvollziehbar: Ein einmal gesetztes integrity-Attribut wird im Tagesgeschäft schnell vergessen, und nach dem ersten gebrochenen Skript nach einem CDN-Update geraten Entwickler in Versuchung, den Schutz lieber ganz zu entfernen, als bei jeder Aktualisierung den Hash neu zu berechnen. Eine kontinuierliche Überwachung dreht dieses Anreizmuster um: Statt SRI als lästige Handarbeit zu behandeln, wird der Zustand der Skript-Absicherung zu einer messbaren Kennzahl, die bei jeder Abweichung sichtbar wird — und genau das verhindert das stille Abrutschen in einen ungeschützten Zustand.

SRI-Checkliste und automatisierte Header-Überwachung

Eine wirksame SRI-Strategie kombiniert sorgfältige Einrichtung mit kontinuierlicher Kontrolle. Die folgende Checkliste fasst die wichtigsten Schritte zusammen — von der ersten Implementierung bis zur laufenden Überwachung.

1. Externe Skripte inventarisieren — alle <script>- und <link>-Tags mit fremder Herkunft erfassen. Ein Security-Scan liefert die vollständige Übersicht inklusive nachgeladener Ressourcen.
2. integrity + crossorigin="anonymous" für jede statische Drittanbieter-Ressource setzen — bevorzugt mit sha384-Hash (W3C SRI).
3. Hash bei jeder Versionsänderung neu generieren — ein Hash gilt nur für genau eine Dateiversion; veraltete Hashes brechen das Skript.
4. CSP ergänzen, um SRI von der Empfehlung zur Pflicht zu machen und ungewollte Quellen grundsätzlich auszuschließen.
5. Ungeschützte und veränderte Externals überwachen — neue Skripte ohne integrity und inhaltlich abweichende Dateien sind Frühwarnsignale.
6. Bezahl- und Formularseiten priorisieren — hier verlangt PCI DSS 6.4.3/11.6.1 ein Skript-Inventar samt Änderungserkennung (PCI Security Standards Council).

Der XICTRAQ Security-Score bewertet Ihre Website unter anderem anhand der gesetzten Sicherheits-Header und der Absicherung externer Ressourcen. Verschwindet ein Schutzmechanismus, taucht ein neues ungeschütztes Skript auf oder ändert sich eine kritische Header-Konfiguration, erhalten Sie über die Alerting-Benachrichtigungen zeitnah einen Hinweis — per E-Mail, Slack, Discord oder Telegram. In Kombination mit dem laufenden Security-Monitoring wird die Absicherung Ihrer Skript-Lieferkette von einer einmaligen Aktion zu einem dauerhaft überwachten Zustand.

Häufig gestellte Fragen zu Subresource Integrity