Was ist Subresource Integrity (SRI)? Leitfaden für WordPress-Seiten

Subresource Integrity (SRI) ist ein W3C-Sicherheitsstandard, mit dem du einen kryptografischen Hash an <script>- und <link>-Tags angeben kannst, damit der Browser verifizieren kann, dass die geladene Datei dem entspricht, was du erwartest. Wenn die Datei unter der URL verändert, abgefangen oder ausgetauscht wurde (sei es durch einen Angreifer, ein kompromittiertes CDN oder selbst durch ein versehentliches Update), blockiert der Browser die Ausführung komplett. SRI wurde 2016 standardisiert und wird von allen großen Browsern unterstützt. Es ist eine der günstigsten Maßnahmen gegen Supply-Chain-Angriffe auf Drittanbieter-JavaScript, was 2026 die dominierende Quelle von Sicherheitsvorfällen auf WordPress-Seiten ist.

Wie sieht ein SRI-Hash aus, und wie füge ich ihn hinzu?

Ein Script-Tag mit aktiviertem SRI hat zwei zusätzliche Attribute: integrity und crossorigin:

<script
  src="https://cdn.example.com/jquery-3.7.1.min.js"
  integrity="sha384-1H217gwSVyLSIfaLxHbE7dRb3v4mYCKbpQvzx0cegeju1MVsGrX5xXxAvs/HgeFs"
  crossorigin="anonymous">
</script>

Der integrity-Wert ist ein base64-kodierter kryptografischer Hash des Datei-Inhalts, mit einem Algorithmus-Präfix (sha256-, sha384- oder sha512-). SHA-384 ist 2026 die empfohlene Wahl: ein guter Kompromiss zwischen Sicherheit und Hash-Länge. SHA-512 ist ebenfalls akzeptabel. SHA-256 funktioniert noch, gilt aber als der schwächste der drei; für unkritische Assets in Ordnung, aber nicht für sicherheitsrelevante Dinge.

Wenn der Browser die Datei lädt, berechnet er ihren Hash und vergleicht ihn mit dem integrity-Wert. Stimmen die Hashes überein, läuft das Script. Unterscheiden sie sich auch nur um ein Byte, weigert sich der Browser, das Script auszuführen, und protokolliert einen Fehler in der Konsole.

Welche Angriffe verhindert Subresource Integrity?

SRI schützt speziell den Fall, dass eine Drittanbieter-Datei zwischen dem Moment, in dem du sie als vertrauenswürdig eingestuft hast, und dem Moment, in dem ein Browser sie tatsächlich lädt, verändert wird. Die drei für WordPress-Seiten relevantesten Szenarien:

• CDN-Kompromittierung. Wenn ein Angreifer in ein CDN eindringt (oder in den Drittanbieter, dessen CDN du nutzt) und eine JavaScript-Datei verändert, würde jede Seite, die diese Datei per <script src> einbindet, plötzlich den Code des Angreifers ausführen. SRI fängt das sofort ab: die veränderte Datei matcht den Hash nicht, der Browser blockiert sie.
• Account-Übernahme beim Drittanbieter. Jemand kompromittiert einen Analytics-, Chat-Widget- oder Font-Hosting-Account und veröffentlicht ein bösartiges Update zu dem Script, das du eingebunden hast. Ohne SRI führt deine Seite das bösartige Update bei jedem Seitenaufruf aus. Mit SRI scheitert das Script still, bis du den Hash aktualisierst, das heißt bis du die neue Version persönlich neu geprüft hast.
• Manipulation auf Netzwerkebene. Ein Man-in-the-Middle-Angreifer in einem Firmennetz oder feindlichen WLAN schreibt eine JavaScript-Datei beim Transit zum Nutzer um. HTTPS verhindert das bei Direktverbindungen zu deinem Origin, aber ein Drittanbieter-Script, das über einen vom Angreifer kontrollierten DNS-Poisoning-Versuch ausgeliefert wird, könnte das umgehen. SRI bietet eine Ende-zu-Ende-Integritätsprüfung unabhängig von TLS.

Der British-Airways-Vorfall 2018, bei dem 380.000 Kunden Zahlungsdaten gestohlen wurden, passierte, weil der Angreifer ein Drittanbieter-Modernizr-Script veränderte, das BA auf der Checkout-Seite lud. SRI auf diesem Script-Tag hätte den Angriff in dem Moment gestoppt, in dem die veränderte Datei geladen wurde. Ähnliche Vorfälle passieren weiter, mit Magecart-artigen Angriffen auf E-Commerce-Seiten als der am besten dokumentierten Kategorie.

Auf welche Dateien sollte ich SRI anwenden?

SRI ist für Drittanbieter-Dateien gedacht, die über das Netzwerk geladen werden. Drei Kategorien zählen, in Prioritätsreihenfolge:

• Zahlungs-, Checkout- und Login-Flows. Jedes JavaScript, das auf einer Seite läuft, auf der Nutzer Kreditkartendaten, Passwörter oder andere sensible Daten eingeben, ist das Ziel mit höchster Priorität. Ein kompromittiertes Script auf einer Checkout-Seite ist das Worst-Case-Szenario. Wenn dein WooCommerce-Checkout irgendetwas von einem CDN lädt, sollten alle diese Scripts SRI haben.
• Global eingebundene Scripts. Alles in <head> oder oben in <body>, was auf jeder Seite läuft: Analytics-Tags, Fonts, Polyfills, jQuery von einem öffentlichen CDN. Die laufen, bevor der Nutzer überhaupt merken kann, dass etwas falsch ist.
• Von Plugins injizierte CDN-Scripts. Viele WordPress-Plugins (Chat-Widgets, A/B-Testing, Marketing-Pixel) laden Remote-JavaScript. Die sind von Dritten geschrieben, denen du implizit vertraut hast, und sie enthalten meist standardmäßig kein SRI.

Umgekehrt: SRI nicht auf Dateien anwenden, die von deiner eigenen Domain ausgeliefert werden. Wenn ein Angreifer Dateien auf deinem Origin-Server verändern kann, kann er auch das HTML verändern, das den Hash deklariert, dann bietet SRI keinen echten Schutz. SRI glänzt nur bei Cross-Origin-Ressourcen.

Wie generiere ich einen SRI-Hash für ein Drittanbieter-Script?

Drei praktische Methoden:

1. srihash.org nutzen. Web-basiertes Tool. Script-URL einfügen, das vollständige <script>-Tag mit Integrity- und Crossorigin-Attributen zurückbekommen. Schnellster Weg für einzelne Ergänzungen.
2. OpenSSL auf der Kommandozeile. curl -s https://cdn.example.com/file.js | openssl dgst -sha384 -binary | openssl base64 -A gibt den base64-Hash aus, dem du sha384- voranstellst. Nützlich für Skripte oder die Arbeit mit lokalen Dateien vor dem Deployment.
3. Doku des Anbieters prüfen. Große CDNs (cdnjs.com, jsDelivr) veröffentlichen den SRI-Hash zu jeder Version jeder gehosteten Bibliothek. Bootstrap, jQuery, Vue, React etc. veröffentlichen alle den empfohlenen Integrity-Wert auf ihren offiziellen Getting-Started-Seiten. Von dort Copy-Paste.

Ein Vorbehalt: der Hash ist an den exakten Byte-Inhalt der Datei gebunden. Wenn das CDN eine andere Version ausliefert (weil du eine URL wie jquery@3 statt jquery@3.7.1 verwendet hast), passt der Hash nicht und das Script wird blockiert. Bei Nutzung von SRI immer auf konkrete Versionen pinnen.

Warum wird das Attribut crossorigin="anonymous" benötigt?

Das crossorigin="anonymous"-Attribut sagt dem Browser, die Drittanbieter-Datei per CORS zu laden, ohne Cookies oder Authentifizierung mitzuschicken. Ohne dieses Attribut kann der Browser den Response-Body der Datei nicht lesen, um deren Hash zu berechnen (eine Eigenheit der Same-Origin-Policy), und die SRI-Prüfung scheitert still und durchlässig: das Script läuft, ohne geprüft zu werden.

Das ist der häufigste SRI-Fehler. Leute fügen integrity hinzu, vergessen aber crossorigin, und nehmen dann an, ihr Setup funktioniert, weil das Script weiter lädt. Ohne beide Attribute hast du keinen echten Schutz. Zum Verifizieren: DevTools öffnen, Netzwerk-Tab, das Script anklicken, Response anschauen. Wenn das CDN CORS unterstützt (was im Grunde alle modernen öffentlichen CDNs tun), siehst du Access-Control-Allow-Origin: * in den Response-Headern. Ohne diesen Header kann SRI auf der Ressource gar nicht funktionieren.

Wie füge ich SRI in WordPress hinzu?

Drei Szenarien, je nachdem, wie Scripts in deine Seiten gelangen:

Szenario 1: per WordPress eingebundene Scripts (Theme oder Plugin)

WordPress-Core unterstützt SRI über den Filter script_loader_tag. In die functions.php deines Child-Themes oder in ein kleines MU-Plugin:

add_filter('script_loader_tag', function ($tag, $handle, $src) {
    $sri_hashes = [
        'jquery'    => 'sha384-1H217gwSVyLSIfaLxHbE7dRb3v4mYCKbpQvzx0cegeju1MVsGrX5xXxAvs/HgeFs',
        'bootstrap' => 'sha384-...dein-hash...',
    ];

    if (isset($sri_hashes[$handle]) && strpos($src, '://') !== false && strpos($src, home_url()) === false) {
        $tag = str_replace(
            ' src=',
            ' integrity="' . $sri_hashes[$handle] . '" crossorigin="anonymous" src=',
            $tag
        );
    }
    return $tag;
}, 10, 3);

Handle-Namen und Hashes an deine Scripts anpassen. Die strpos-Checks stellen sicher, dass SRI nur auf Scripts von externen Domains angewendet wird, nicht auf deine eigenen.

Szenario 2: fest in Theme-Templates eingetragene Scripts

Wenn ein Theme direkt <script src="https://...">-Tags in header.php oder anderswo ausgibt, diese Tags direkt bearbeiten und Integrity- und Crossorigin-Attribute ergänzen. Im Child-Theme spiegeln, damit Parent-Theme-Updates die Änderung nicht überschreiben.

Szenario 3: Scripts, die per JavaScript oder Drittanbieter-Plugins zur Laufzeit injiziert werden

Chat-Widgets, A/B-Testing-Tools und Tag-Manager injizieren Script-Tags oft dynamisch. SRI funktioniert auch hier: das dynamisch erzeugte <script>-Element muss die Properties integrity und crossOrigin setzen, bevor das Script ins DOM gehängt wird. Die meisten Enterprise-Versionen dieser Tools unterstützen das per Konfiguration; die Free-Tiers meist nicht. Für nicht gemanagte Drittanbieter-Injektionen ist der praktische Fallback eine Content Security Policy mit require-sri-for script (noch im Draft) oder schlicht sorgfältiges Auditing.

Wie groß ist der Wartungsaufwand von SRI?

Das ist der ehrliche Trade-off. SRI ist ein Kompromiss zwischen Sicherheit und Komfort. Jedes Mal, wenn die Upstream-Bibliothek aktualisiert wird, ändert sich der Hash, dein Script bricht, und du musst den Hash anpassen. Für eine stabile Seite, die Versionen pinnt und sie selten aktualisiert, ist das eine Aufgabe alle paar Monate. Für eine Seite, die jquery@latest nutzt oder auf auto-aktualisierende CDNs setzt, ist SRI eine ständige Bruchstelle.

Drei Muster, die SRI-Wartung handhabbar machen:

• Auf konkrete Versionen pinnen, nicht "latest". URL wie https://cdn.jsdelivr.net/npm/jquery@3.7.1/dist/jquery.min.js, nicht jquery@latest. Der Hash bleibt dann stabil, bis du bewusst upgradest.
• Ein CDN nutzen, das Hashes veröffentlicht. cdnjs und jsDelivr veröffentlichen beide den SRI-Hash für jede Datei. Den Hash bei einem Upgrade zu aktualisieren ist eine 30-Sekunden-Aufgabe.
• Kritische Bibliotheken selbst hosten. Sobald du selbst hostest (was du aus DSGVO-Gründen sowieso in Erwägung ziehen solltest, siehe Google-Fonts-Diskussion), wird SRI für dieses Script irrelevant. SRI ist für Fälle gedacht, in denen du nicht selbst hosten kannst. Für Analytics, Fonts, Bibliotheken, die nur auf einer Seite genutzt werden, ist Self-Hosting oft die bessere Antwort.

Häufige Fehler

• crossorigin="anonymous" vergessen. Das Script lädt weiter, aber wird nicht mehr integritätsgeprüft. Der häufigste stille SRI-Fehler.
• SRI auf Same-Origin-Ressourcen. Ein Angreifer, der /wp-includes/js/jquery.js verändern kann, kann auch das HTML ändern, das den Hash deklariert. SRI nur auf Cross-Origin-Ressourcen anwenden.
• Hash auf der falschen Dateiversion berechnen. Der Hash muss exakt zu den Bytes passen, die der Browser empfängt, inklusive jeder CDN-seitigen Minifizierung oder Transformation. Beim Berechnen immer von der tatsächlichen Produktions-URL holen.
• Hash beim Bibliotheks-Upgrade nicht aktualisieren. Bibliotheksversion in der URL upgraden, integrity vergessen zu aktualisieren, das Script funktioniert still nicht mehr. Symptome: ein Feature bricht, die Konsole zeigt "Failed to find a valid digest in the integrity attribute".
• SHA-1 nutzen. SHA-1 ist kollisionsanfällig und für SRI deprecated. SHA-384 oder SHA-512 nutzen.
• SRI auf einem CDN ohne CORS versuchen. Der Browser kann den Hash nicht berechnen, SRI ist also unmöglich. Entweder das CDN muss CORS aktivieren, oder du musst die Datei selbst hosten.

SRI und Content Security Policy (CSP)

SRI und CSP ergänzen sich, sie sind nicht redundant. CSP sagt "nur Scripts von dieser Liste von Ursprüngen dürfen laufen". SRI sagt "und dieses Script muss diesem exakten Hash entsprechen". Zusammen bilden sie einen Defense-in-Depth-Ansatz: CSP blockiert unbekannte Origins; SRI blockiert Manipulation an bekannten Origins. Ein CSP mit script-src 'self' https://trusted-cdn.com sagt "wir vertrauen trusted-cdn.com"; SRI-Hashes für deine Scripts auf trusted-cdn.com schränken dieses Vertrauen auf konkrete Dateiversionen ein.

Die Draft-Direktive require-sri-for script in CSP würde erzwingen, dass jedes Cross-Origin-Script ein Integrity-Attribut haben muss, auf Browser-Ebene. Stand 2026 hat sie begrenzten Support, ist aber die Richtung, in die der Standard sich bewegt.

Was InspectWP prüft

Der Security-Abschnitt jedes InspectWP-Reports inspiziert externe Script- und Stylesheet-Tags und meldet, welche davon Integrity-Attribute haben und welche nicht. Fehlt SRI bei einem Script von einem Drittanbieter-CDN, wird das je nach Kontext als Befund mit niedriger bis mittlerer Schwere geflaggt. Eine Login- oder Checkout-Seite, die externes JavaScript ohne SRI lädt, ist eine Warnung mit höherer Priorität. Der Report markiert auch fehlerhafte Integrity-Werte (falsches Algorithmus-Präfix, ungültiges base64), die ein trügerisches Sicherheitsgefühl geben, vom Browser aber tatsächlich ignoriert werden. SRI gehört zu den Maßnahmen, bei denen die Existenz des Attributs weniger zählt als seine Korrektheit; ein falscher Hash ist funktional einem fehlenden Hash gleichzusetzen, weil der Browser Mismatches weiter ablehnt, aber ein fehlendes crossorigin-Attribut macht die ganze Prüfung still wirkungslos.