Cache-Control für Shopware 6
Sicherheitsrelevante Cache-Direktiven über shopware.yaml http_cache und EventSubscriber — Varnish-Integration und no-store für Checkout.
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.
# 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 // 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;
}
}
} # 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);
}
} 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.
# 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) 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
Wie steht Ihre Domain bei Cache-Control?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.