Das CDN liefert JavaScript – ist es noch die Datei, die Sie freigegeben haben?

HTTPS schützt die Verbindung. Es beweist nicht, dass eine Datei auf einem legitimen CDN oder Drittanbieter-Host seit Ihrer letzten Prüfung unverändert geblieben ist. Wird ein Anbieter kompromittiert oder eine Datei unter derselben URL ersetzt, kann der Browser weiterhin sauber verschlüsseltes JavaScript laden – nur eben anderes JavaScript.

Subresource Integrity (SRI) ergänzt deshalb zur URL einen kryptografischen Hash. Der Browser prüft vor der Ausführung, ob die geladenen Bytes zum erwarteten Hash passen. Bei einer Abweichung wird die Ressource nicht ausgeführt.

Der W3C-Arbeitsentwurf zu Subresource Integrity Level 2 vom 20. März 2026 führt diesen Ansatz weiter und definiert zusätzlich Integrity-Policy sowie Integrity-Policy-Report-Only.

Mythos: „HTTPS reicht für ein CDN-Skript“

HTTPS beantwortet: „Spreche ich verschlüsselt mit dem erwarteten Host?“

SRI beantwortet: „Ist das exakt die Datei, die ich freigegeben habe?“

Das ist relevant für CDN-Bibliotheken, Zahlungs- und Support-Widgets, Analytics, Consent-Tools, A/B-Testing und andere externe Frontend-Abhängigkeiten. OWASP weist darauf hin, dass Drittanbieter-JavaScript außerhalb des eigenen Release-Prozesses geändert werden und im Kontext der eigenen Website Code ausführen kann.

Was SRI tatsächlich prüft

Für unterstützte script- und link-Ressourcen kann das integrity-Attribut Hashes mit SHA-256, SHA-384 oder SHA-512 enthalten. Beispiel:

<script src="https://cdn.example.com/widget-4.2.1.js" integrity="sha384-…" crossorigin="anonymous"></script>

Der Browser berechnet den Hash der Antwort. Passt er nicht, schlägt die Ressource als Netzwerkfehler fehl.

Das ist Sicherheitsgewinn und Betriebsrisiko zugleich: Wenn ein Anbieter https://vendor.example/latest.js still verändert, verhindert SRI die Ausführung – kann aber damit auch eine Funktion Ihrer Website ausfallen lassen.

Deshalb gehören versionierte, möglichst unveränderliche URLs und SRI zusammen. Ein Update sollte bewusst erfolgen: neue Version prüfen, testen, Hash aktualisieren und URL plus Hash gemeinsam deployen.

Mehrere Hashes brauchen Governance

SRI erlaubt mehrere Hashwerte. Laut W3C und MDN verwendet der Browser die stärkste angegebene unterstützte Hash-Funktion; mehrere Hashes derselben Stärke können mehrere ausdrücklich erlaubte Varianten abdecken.

Das kann bei einem kontrollierten Rollout helfen. Es sollte aber nicht zu einer ewigen Liste alter Freigaben werden. Prüfen Sie deshalb:

• wer Hashes erzeugt und freigibt,
• warum mehrere Werte vorhanden sind,
• welche Versionen noch gültig sind,
• wann alte Hashes entfernt werden.

Cross-Origin-SRI braucht CORS

Für externe Ressourcen setzt SRI CORS voraus. Der Drittanbieter muss passende CORS-Header senden; im Markup wird typischerweise crossorigin="anonymous" verwendet.

Ein häufiger Fehler ist deshalb, SRI direkt in Produktion zu ergänzen und erst danach festzustellen, dass der Anbieter die Ressource nicht passend für CORS ausliefert. Testen Sie Hash, CORS und Fehlerpfad gemeinsam.

Die Tag-Manager-Falle

Ein Hash auf einem Loader schützt zunächst diesen Loader. Er attestiert nicht automatisch jedes Skript, das anschließend dynamisch geladen wird.

Gerade Tag Manager, Consent-Plattformen und Widget-Bootstrapper können weitere Ressourcen von anderen Hosts nachladen. Der eigentliche Check lautet daher nicht nur:

„Hat unser Script-Tag ein integrity-Attribut?“

sondern:

„Welche ausführbaren Ressourcen entstehen aus diesem Einstiegspunkt?“

Inventarisieren Sie deshalb im Browser-Netzwerk nicht nur HTML-Tags, sondern die reale Lade-Kette.

Neu in SRI Level 2: Integrity Policy

Der aktuelle W3C-Arbeitsentwurf beschreibt Integrity-Policy und Integrity-Policy-Report-Only. Damit kann ein Dokument für bestimmte Ressourcentypen, aktuell insbesondere Skripte und Stylesheets, Integritätsmetadaten verlangen und Verstöße melden.

Der sinnvolle Rollout beginnt im Berichtmodus:

1. Integrity-Policy-Report-Only aktivieren,
2. Verstöße sammeln,
3. vergessene oder dynamische Ressourcen identifizieren,
4. SRI- und CORS-Lücken schließen,
5. erst danach blockierende Durchsetzung erwägen.

MDN kennzeichnet Integrity-Policy derzeit als Limited availability. Die Funktion sollte deshalb nicht die einzige Schutzschicht sein. Report-Only ist vor allem ein nützliches Werkzeug, um Abhängigkeiten sichtbar zu machen.

Ein praktischer SRI-Check

Prüfen Sie auf einer produktiven Seite:

• Welche Drittanbieter-Skripte und Styles werden tatsächlich geladen?
• Sind deren URLs versioniert oder mutieren sie unter Namen wie latest, loader oder embed?
• Wo fehlt SRI bei statischen, versionierbaren Dateien?
• Funktionieren CORS und crossorigin?
• Was passiert bei einem absichtlich falschen Hash?
• Welche Skripte laden weitere Skripte nach?
• Wer verantwortet Vendor-Updates, neue Hashes und Regressionstests?

Was Website-Pflichtencheck prüfen würde

Website-Pflichtencheck kann die reale externe Lade-Kette untersuchen: Drittanbieter-Hosts, mutable und versionierte URLs, SRI-Metadaten, Hash-Verfahren, CORS, dynamische Nachlade-Ketten, Tag-Manager-Abhängigkeiten, Fehlerverhalten und den praktischen Update-Prozess.

Wo es zum Projekt passt, lässt sich zusätzlich prüfen, ob Integrity-Policy-Report-Only als Beobachtungsinstrument sinnvoll eingesetzt werden kann.

Das Ziel ist nicht, externe Skripte pauschal zu verbieten. Das Ziel ist, aus „Wir vertrauen dieser URL“ eine überprüfbare Aussage zu machen:

„Wir wissen, welche Datei freigegeben ist, wir bemerken Abweichungen und wir haben einen kontrollierten Weg für Updates.“