Subresource Integrity für Shopware 6
Hash-Prüfung externer Scripts in Twig-Templates — Shopware Asset-System und Build-Pipeline für manipulationssichere Ressourcen.
Subresource Integrity in Shopware 6
Subresource Integrity (SRI) stellt sicher, dass externe Scripts und Stylesheets nicht manipuliert wurden. Der Browser vergleicht einen SHA-Hash im integrity-Attribut mit der heruntergeladenen Datei und blockiert die Ausführung bei Abweichungen. SRI ist mit 15 von 166 Punkten im Wolf-Agents Web Security Check bewertet — einer der höchstbewerteten Einzelheader.
In Shopware 6 werden Scripts über Twig-Templates eingebunden. Shopware bietet keine native SRI-Unterstützung — die Implementierung erfolgt über Template-Anpassungen in Ihrem Theme oder Plugin. Besonders kritisch sind Payment-Provider-Scripts (Stripe, PayPal, Klarna, Mollie), die auf Checkout-Seiten geladen werden: PCI DSS 4.0 Requirement 6.4.3 fordert die Integritätsprüfung aller Scripts auf Zahlungsseiten.
Die Herausforderung bei Shopware liegt im Asset-System: Nach jedem bin/console theme:compile oder bin/build-storefront.sh ändern sich die Asset-Dateien und damit auch die SRI-Hashes. Für eigene Assets empfiehlt sich eine Build-Pipeline mit automatischer Hash-Generierung. Für externe Scripts (Payment-Provider) müssen Hashes manuell gepflegt werden. Der Wolf-Agents Web Security Scanner erkennt automatisch, ob SRI-Attribute auf externen Scripts gesetzt sind.
Implementierung
Variante A: integrity-Attribut direkt in Twig-Templates für Payment-Scripts setzen. Variante B: Hash-Generierung über die Kommandozeile. Variante C: Automatische SRI-Hashes in der Build-Pipeline für eigene Assets.
<!-- Twig-Template: SRI für externe Payment-Scripts -->
<!-- Resources/views/storefront/base.html.twig -->
{% block base_script_hmr %}
{% sw_include '@Storefront/storefront/page/checkout/payment-scripts.html.twig' %}
{% endblock %}
<!-- payment-scripts.html.twig -->
<script
src="https://js.stripe.com/v3/"
integrity="sha384-[HASH-HIER-EINFÜGEN]"
crossorigin="anonymous"
></script>
<!-- Für PayPal SDK -->
<script
src="https://www.paypal.com/sdk/js?client-id=CLIENT_ID"
integrity="sha384-[HASH-HIER-EINFÜGEN]"
crossorigin="anonymous"
data-csp-nonce="{{ sw_csrf('') }}"
></script> # SRI-Hash für eine externe Datei generieren
curl -s https://js.stripe.com/v3/ | \
openssl dgst -sha384 -binary | \
openssl base64 -A
# Ergebnis als integrity-Attribut verwenden:
# integrity="sha384-[ERGEBNIS]"
# Mehrere Hashes für Fallback (SHA-256 + SHA-384)
# Nützlich für schrittweise Migration
FILE_URL="https://js.stripe.com/v3/"
SHA256=$(curl -s $FILE_URL | openssl dgst -sha256 -binary | openssl base64 -A)
SHA384=$(curl -s $FILE_URL | openssl dgst -sha384 -binary | openssl base64 -A)
echo "integrity=\"sha256-$SHA256 sha384-$SHA384\"" // Build-Pipeline: SRI-Hashes automatisch generieren
// webpack.config.js im Custom Theme
const SriPlugin = require('webpack-subresource-integrity');
module.exports = {
plugins: [
new SriPlugin({
hashFuncNames: ['sha384'],
enabled: process.env.NODE_ENV === 'production',
}),
],
output: {
crossOriginLoading: 'anonymous',
},
}; Stripe, PayPal und Klarna aktualisieren ihre Scripts regelmäßig ohne Vorankündigung. SRI-Hashes müssen nach jedem Update aktualisiert werden, da der Browser sonst das Script blockiert und der Checkout nicht funktioniert. Für dynamische Provider-Scripts gibt es zwei Strategien: (1) Hashes regelmäßig per Cron-Job prüfen und aktualisieren, oder (2) auf SRI für diese Scripts verzichten und stattdessen eine strikte CSP mit script-src Whitelist nutzen. PCI DSS 4.0 akzeptiert beide Ansätze.
Verifizierung
Prüfen Sie SRI-Attribute in drei Schritten: Cache leeren, Theme kompilieren, HTML-Ausgabe kontrollieren. Testen Sie unbedingt auch die Checkout-Seite separat, da Payment-Scripts oft nur dort geladen werden.
# 1. Shopware-Cache leeren nach Template-Änderungen
bin/console cache:clear
# 2. Theme neu kompilieren (generiert neue Asset-Hashes)
bin/console theme:compile
# 3. SRI-Attribute in der HTML-Ausgabe prüfen
curl -s https://ihr-shop.de | grep -i integrity
# Erwartete Ausgabe: integrity="sha384-..." crossorigin="anonymous"
# 4. Browser DevTools: Console zeigt SRI-Fehler
# Fehler: "Failed to find a valid digest in the 'integrity' attribute"
# → Hash stimmt nicht mit Dateiinhalt überein
# 5. Checkout-Seite separat prüfen (Payment-Scripts)
curl -s https://ihr-shop.de/checkout/confirm | grep -i integrity Häufige Fehler
Payment-Script-Update bricht SRI-Prüfung
Stripe und PayPal aktualisieren ihre Scripts regelmäßig. Wenn sich der Inhalt ändert, blockiert der Browser das Script und der Checkout ist unbenutzbar. Überwachen Sie Hash-Änderungen und haben Sie einen Fallback-Mechanismus, der SRI temporär deaktiviert.
crossorigin-Attribut fehlt
SRI funktioniert nur mit crossorigin="anonymous" bei Cross-Origin-Scripts. Ohne dieses Attribut wird der Hash nicht geprüft und SRI ist wirkungslos. Der Browser lädt das Script, führt aber keine Integritätsprüfung durch.
Shopware-Build ändert Asset-Hashes
Nach bin/console theme:compile oder bin/build-storefront.sh ändern sich die Asset-Dateien. SRI-Hashes für eigene Assets müssen nach jedem Build neu generiert werden. Nutzen Sie das webpack-subresource-integrity Plugin für automatische Generierung.
CDN liefert andere Version als erwartet
Wenn Ihr CDN (z.B. Bunny.net, Cloudflare) eine andere Version oder komprimierte Variante der Datei ausliefert, stimmt der Hash nicht überein. Stellen Sie sicher, dass der Hash auf der tatsächlich ausgelieferten Datei basiert — nicht auf der Quell-Datei.
Compliance-Relevanz
Wie steht Ihre Domain bei Subresource Integrity?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.