Cache-Control für Shopware 6

Sicherheitsrelevante Cache-Direktiven über shopware.yaml http_cache und EventSubscriber — Varnish-Integration und no-store für Checkout.

Shopware · Schritt für Schritt

Cache-Control in Shopware 6

Cache-Control steuert, wie Browser und Proxies HTTP-Responses cachen. Für Shopware-Shops ist die korrekte Konfiguration sicherheitskritisch: Checkout-Seiten mit Zahlungsdaten, Account-Bereiche mit persönlichen Informationen und die Administration dürfen unter keinen Umständen gecacht werden. Cache-Control ist mit 8 von 166 Punkten im Wolf-Agents Web Security Check bewertet.

Shopware 6 bietet ein natives HTTP-Cache-System über die shopware.yaml-Konfiguration. Für öffentliche Seiten (Produktlisten, Kategorien, CMS-Seiten) setzt Shopware automatisch sinnvolle Cache-Header. Das Problem liegt bei den sensiblen Seiten: Shopware setzt dort zwar private, aber nicht immer no-store. Ein EventSubscriber mit explizitem no-store auf Checkout-, Account- und Admin-Routen schließt diese Lücke.

Wenn Sie Varnish als Reverse-Proxy einsetzen, wird die Konfiguration komplexer: Varnish cached standardmäßig alles, was keinen no-store-Header hat. Custom-VCL-Regeln können Shopware's Cache-Control überschreiben. Prüfen Sie die gesamte Cache-Kette: Shopware HTTP Cache, Varnish, CDN (Bunny.net, Cloudflare) und Browser-Cache. Der Wolf-Agents Web Security Scanner prüft automatisch die Cache-Control-Header Ihres Shops.

Implementierung

Variante A: HTTP Cache Grundkonfiguration in shopware.yaml. Variante B: EventSubscriber für no-store auf sensiblen Seiten. Variante C: Varnish VCL für korrekte Cache-Control-Weiterleitung.

Variante A — shopware.yaml
config/packages/shopware.yamlHTTP Cache
# config/packages/shopware.yaml — HTTP Cache
shopware:
    http_cache:
        enabled: true
        default_ttl: 7200
        # Stale-While-Revalidate: 30 Sekunden
        # Liefert gecachte Version während im Hintergrund aktualisiert wird
        stale_while_revalidate: 30
        # Stale-If-Error: 24 Stunden Fallback bei Backend-Fehlern
        stale_if_error: 86400

    # Cache-Invalidierung konfigurieren
    cache:
        invalidation:
            # Produkt-Cache automatisch invalidieren bei Änderungen
            product_listing_route: true
            product_detail_route: true
Variante B — EventSubscriber
SecurityHeaderSubscriber.phpSicherheit
// EventSubscriber — no-store für sensible Seiten
public function onResponse(ResponseEvent $event): void
{
    $request = $event->getRequest();
    $response = $event->getResponse();
    $path = $request->getPathInfo();

    // Sensible Bereiche: Kein Caching erlaubt
    $noCachePaths = [
        '/checkout',    // Warenkorb, Bestellung, Zahlung
        '/account',     // Kundendaten, Bestellhistorie
        '/admin',       // Administration
        '/store-api',   // API-Responses mit Kundendaten
    ];

    foreach ($noCachePaths as $prefix) {
        if (str_starts_with($path, $prefix)) {
            $response->headers->set(
                'Cache-Control',
                'no-store, no-cache, must-revalidate, private'
            );
            // Pragma für ältere Proxies
            $response->headers->set('Pragma', 'no-cache');
            return;
        }
    }
}
Variante C — Varnish VCL
default.vclVarnish
# Varnish VCL — Cache-Control respektieren
# /etc/varnish/default.vcl (Auszug)

sub vcl_backend_response {
    # no-store IMMER respektieren
    if (beresp.http.Cache-Control ~ "no-store") {
        set beresp.uncacheable = true;
        set beresp.ttl = 0s;
        return (deliver);
    }

    # Checkout und Account nie cachen
    if (bereq.url ~ "^/(checkout|account|admin)") {
        set beresp.uncacheable = true;
        set beresp.ttl = 0s;
        return (deliver);
    }
}
Varnish und Shopware HTTP Cache

Shopware's interner HTTP Cache und Varnish sollten nicht gleichzeitig aktiv sein. Wenn Sie Varnish nutzen, deaktivieren Sie den Shopware HTTP Cache: SHOPWARE_HTTP_CACHE_ENABLED=0 in der .env. Varnish übernimmt dann das komplette Caching. Stellen Sie sicher, dass Ihre VCL no-store respektiert und Checkout-Pfade nie cached — auch nicht bei versehentlich fehlenden Headern.

Verifizierung

Prüfen Sie Cache-Control für verschiedene Seitentypen: Produktseiten sollten gecacht sein (Performance), Checkout und Account müssen no-store haben (Sicherheit). Bei Varnish prüfen Sie zusätzlich den X-Cache-Header.

TerminalVerifizierung
# 1. Beide Caches leeren
bin/console cache:clear
bin/console http:cache:clear

# 2. Cache-Control für Produktseite (sollte gecacht sein)
curl -sI https://ihr-shop.de/beispiel-produkt | grep -i cache-control
# Erwartete Ausgabe: Cache-Control: public, s-maxage=7200

# 3. Cache-Control für Checkout (MUSS no-store sein)
curl -sI https://ihr-shop.de/checkout/cart | grep -i cache-control
# Erwartete Ausgabe: Cache-Control: no-store, no-cache, must-revalidate, private

# 4. Cache-Control für Account (MUSS no-store sein)
curl -sI https://ihr-shop.de/account | grep -i cache-control
# Erwartete Ausgabe: Cache-Control: no-store, no-cache, must-revalidate, private

# 5. Bei Varnish: X-Cache Header prüfen
curl -sI https://ihr-shop.de/beispiel-produkt | grep -i x-cache
# Erwartete Ausgabe: X-Cache: HIT (bei zweitem Aufruf)
Tipp: Testen Sie immer den gesamten Checkout-Flow nach Cache-Änderungen. Ein falsch konfigurierter Cache kann dazu führen, dass Kunde A die Bestelldaten von Kunde B sieht — der schwerwiegendste Datenschutzvorfall eines Shops.

Häufige Fehler

Kundendaten im Cache gespeichert

Ohne no-store auf Account- und Checkout-Seiten können personenbezogene Daten (Name, Adresse, Bestellhistorie) im Browser- oder Proxy-Cache landen. Auf gemeinsam genutzten Geräten kann der nächste Benutzer die Daten sehen. Das verletzt DSGVO Art. 32.

HTTP Cache liefert gecachte Security-Header

Shopware cached auch HTTP-Response-Header. Wenn Sie Security-Header nach dem Cache-Aufbau hinzufügen, fehlen sie auf gecachten Seiten. Lösung: bin/console cache:clear und bin/console http:cache:clear nach jeder Header-Änderung.

Varnish ignoriert no-store

Custom-VCL-Regeln können no-store überschreiben — besonders wenn beresp.ttl manuell gesetzt wird. Prüfen Sie die Varnish-Konfiguration auf Regeln, die den Cache-Control Header entfernen oder überschreiben. Nutzen Sie varnishlog zur Diagnose.

CDN cached Checkout-Seiten

CDNs wie Cloudflare oder Bunny.net können Shopware-Seiten cachen, obwohl sie no-store haben. Prüfen Sie die CDN-Konfiguration: Erstellen Sie eine Page Rule die /checkout/* und /account/* vom Caching ausschließt. Bei Bunny.net: Cache Strip auf Checkout-URLs setzen.

Compliance-Relevanz

DSGVO Art. 32 — Personenbezogene Daten dürfen nicht in öffentlichen Caches gespeichert werden. Kundendaten auf Account-Seiten und Bestellinformationen im Checkout erfordern zwingend no-store.
PCI DSS 4.0 Requirement 6.2.4 — Zahlungsdaten dürfen weder im Browser-Cache noch in Proxy-Caches gespeichert werden. Checkout-Seiten mit Kreditkartendaten erfordern no-store und private.
NIS2 Art. 21(e) — Technische Maßnahmen gegen unbeabsichtigte Datenspeicherung. Cache-Control ist eine grundlegende Maßnahme zur Vermeidung von Datenabfluss durch Caching-Mechanismen.
BSI APP.3.1 — Vertraulichkeit von Sitzungsdaten sicherstellen. Das BSI empfiehlt no-store für alle Seiten mit personenbezogenen Daten oder Authentifizierungsinformationen.

Wie steht Ihre Domain bei Cache-Control?

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