Subresource Integrity für Shopware 6

Hash-Prüfung externer Scripts in Twig-Templates — Shopware Asset-System und Build-Pipeline für manipulationssichere Ressourcen.

Shopware · Schritt für Schritt

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.

Variante A — Twig-Template
Resources/views/storefront/base.html.twigTwig-Template
<!-- 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>
Variante B — Hash generieren
TerminalHash generieren
# 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\""
Variante C — Build-Pipeline
webpack.config.jsAutomatisch
// 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',
    },
};
SRI und Payment-Provider-Scripts

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.

TerminalVerifizierung
# 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
Tipp: Der Wolf-Agents Web Security Check erkennt automatisch fehlende SRI-Attribute auf externen Scripts und bewertet die Implementierung mit bis zu 15 Punkten.

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

PCI DSS 4.0 Requirement 6.4.3 — Integritätsprüfung aller auf Zahlungsseiten geladenen Scripts ist ab März 2025 Pflicht. SRI ist der empfohlene Mechanismus für diese Anforderung in Shopware-Shops mit Kartenzahlung.
NIS2 Art. 21(d) — Sicherheit der Lieferkette einschließlich der Sicherheit zwischen Einrichtungen und Dritten. SRI schützt vor kompromittierten CDN-Servern und Supply-Chain-Angriffen.
BSI APP.3.1 — Integritätssicherung externer Ressourcen als Maßnahme gegen Web-Skimming und Magecart-Angriffe auf E-Commerce-Plattformen.
OWASP ASVS V14.2 — Dependency Integrity: Alle extern geladenen Ressourcen müssen auf Integrität geprüft werden, um Supply-Chain-Angriffe zu verhindern.

Wie steht Ihre Domain bei Subresource Integrity?

Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.