SaaSFort Subresource Integrity gibt es seit einem Jahrzehnt. Sie hinterlegen einen Hash am Skript-Tag, der Browser prüft vor der Ausführung, ob die Datei übereinstimmt, und ein kompromittiertes CDN kann Ihnen keinen veränderten Code mehr ausliefern.
Das funktioniert. Es hat auch einen strukturellen Mangel, der nichts mit Kryptografie zu tun hat: Es ist freiwillig, Tag für Tag.
Wie die SRI-Abdeckung zerfällt
Ein Team prüft seine Drittanbieter-Skripte, ergänzt überall integrity-Attribute und besteht die Kontrolle.
Sechs Monate später gibt es einen neuen Analytics-Anbieter, ein vom Marketing eingebundenes Support-Widget und einen aus einem Dashboard kopierten A/B-Testing-Schnipsel. Keines davon trägt ein Integritätsattribut, weil es niemand verlangt hat.
Ihre SRI-Abdeckung ist nun teilweise, und teilweise schützt gar nicht: Ein Angreifer, der das CDN kompromittiert, braucht nur ein einziges ungeschütztes Skript.
Das ist der Normalfall, kein Disziplinproblem. Jeder Kontrollmechanismus, der darauf beruht, dass sich jede künftige Entwicklerin daran erinnert, wird verfallen.
Was Integrity-Policy leistet
Integrity-Policy ist ein Response-Header aus SRI Level 2, der die Anforderung vom Tag auf die Seite verschiebt. Ist er gesetzt, blockiert der Browser jede Anfrage an das angegebene Ziel, die ohne Integritätsmetadaten eintrifft.
Integrity-Policy: blocked-destinations=(script), endpoints=(integrity-endpoint)
Reporting-Endpoints: integrity-endpoint="https://ihredomain.de/_reports/integrity"
Das Skript, das jemand im nächsten Quartal ohne integrity-Attribut ergänzt, wird nicht ausgeführt. Es funktioniert nicht halb und scheitert nicht still auf eine Weise, die niemandem auffällt: Es wird blockiert, und ein Bericht geht raus.
Ebenso blockiert der Header Anfragen im No-cors-Modus vollständig und schließt damit den Weg, auf dem ein Skript in einem Modus geladen wird, der die Integritätsprüfung unmöglich macht.
Die Falle, die Sie einplanen sollten
In Integrity-Policy lässt sich nicht zwischen Erstanbieter- und Drittanbieter-Ressourcen unterscheiden.
Wenn Sie ihn aktivieren, braucht jedes Skript ein Integritätsattribut, auch Ihre eigenen Bundles. Für eine Seite mit gehashten Build-Ausgaben ist das ein Build-Schritt. Für eine Seite, die /app.js ausliefert und bei jedem Deployment überschreibt, ist es eine echte Änderung an der Pipeline, denn der Hash im HTML muss mit dem Bundle neu erzeugt werden.
Das ist so gewollt. Der Header entstammt dem Bestreben, dem Web eine Code-Signatur nach Art der App-Stores zu geben, bei der die Zusage lautet, dass nichts auf der Seite manipuliert wurde, und nicht bloß die Drittanbieteranteile.
Planen Sie es ein. Das Build-Werkzeug der meisten Frameworks erzeugt SRI-Hashes über eine Option oder ein kleines Plugin, aber es ist eine bewusst zu treffende Änderung und keine, die man in der Produktion entdecken sollte.
Browserunterstützung 2026
| Browser | Stand |
|---|---|
| Chromium | Ausgeliefert ab Chrome 130 |
| Firefox | Teilweise ab Firefox 145, nur Ziel script |
| Safari | Noch nicht |
Teilweise Abdeckung lohnt das Deployment dennoch. Der Header wird ignoriert, wo er nicht unterstützt wird, es besteht also kein Kompatibilitätsrisiko, und der überwiegende Teil des Verkehrs erhält die Durchsetzung.
Zuerst im Report-only-Modus ausrollen
Integrity-Policy-Report-Only: blocked-destinations=(script), endpoints=(integrity-endpoint)
Im Report-only-Modus lässt der Browser die verstoßende Anfrage zu und meldet sie. Das ist der sichere erste Schritt, und er liefert früh genau das, was Sie eigentlich wollen: eine vollständige Liste aller derzeit ohne Integritätsmetadaten ausgelieferten Skripte, erhoben aus echten Seitenaufrufen statt aus einem Crawl.
Arbeiten Sie diese Liste auf null herunter, dann stellen Sie den Header auf Durchsetzung um.
Verstöße lassen sich zusätzlich in JavaScript mit einem für integrity-violation registrierten ReportingObserver beobachten, was während der Migration nützlich ist.
Warum das in eine Lieferantenantwort gehört
Die Lieferkettenkompromittierung über ein Drittanbieter-Skript ist einer der wenigen Angriffe, der praktisch alle Kontrollmechanismen umgeht, nach denen ein SaaS-Anbieter üblicherweise gefragt wird. Der Code wird von einer erlaubten Herkunft über TLS an einen authentifizierten Nutzer ausgeliefert, in einer Seite mit gültiger CSP. CSP schützt ausdrücklich nicht davor: Sie prüft, woher ein Skript kommt, nicht, was es enthält.
Sicherheitsteams auf Unternehmensseite fragen das inzwischen direkt, meist formuliert als “wie erkennen Sie die Veränderung von Drittanbieter-Code in Ihrer Anwendung”. “Wir pinnen Integritäts-Hashes und lassen sie über Integrity-Policy im Browser durchsetzen” ist eine deutlich bessere Antwort als “wir prüfen unsere Anbieter”.
Sie ergänzt eine SBOM, ohne sie zu ersetzen: Die SBOM sagt, wovon Sie abhängen, die Integritätsrichtlinie stellt sicher, dass ausgeliefert wird, was Sie freigegeben haben.
Zuordnung zu Rahmenwerken
- NIS2 Artikel 21(2)(d), Sicherheit der Lieferkette, und 21(2)(g), Cyberhygiene.
- ISO/IEC 27001:2022 A.5.21 (Management der IKT-Lieferkette) und A.8.28 (sichere Entwicklung).
- DORA Artikel 28, IKT-Drittparteienrisiko, sowie Artikel 6.
Prüfung
curl -sI https://ihredomain.de | grep -i "integrity-policy"
Ein SaaSFort-Scan unterscheidet drei Zustände, weil sie betrieblich Unterschiedliches bedeuten: durchgesetzt, nur meldend, abwesend. Report-only ist Fortschritt, kein Schutz.
Kurzfassung
SRI ist ein Versprechen pro Tag, das zerfällt. Integrity-Policy ist eine Regel auf Seitenebene, die das nicht tut.
Beginnen Sie mit Integrity-Policy-Report-Only, nutzen Sie die Berichte als Inventar, dann erzwingen Sie.
Von der Theorie zur Praxis
Scannen Sie Ihre Domain kostenlos. Erste Ergebnisse in unter 10 Sekunden — ohne Registrierung.