Cache-Control für Nuxt 3 konfigurieren
Schritt-für-Schritt: Sicherheitsrelevante Cache-Direktiven in Nuxt 3 — für Assets, HTML-Seiten und sensible API-Routen.
Cache-Control in Nuxt 3
Cache-Control steuert, wie Browser und CDNs Ressourcen zwischenspeichern. Falsche Einstellungen können sensible Daten in öffentlichen Caches speichern oder veraltete Sicherheitsheader ausliefern. Mit 8 von 166 Punkten ist Cache-Control ein relevanter Faktor im Wolf-Agents Web Security Check.
Nuxt 3 setzt automatisch optimale Cache-Header für /_nuxt/-Assets (immutable, 1 Jahr TTL). Für HTML-Seiten und API-Routen müssen Sie Cache-Control manuell konfigurieren — insbesondere für Dashboard-, Login- und Account-Seiten, die personenbezogene Daten enthalten. Ohne explizite Konfiguration können CDNs oder Shared Proxies diese Seiten zwischenspeichern.
Wichtig: Bei nuxt generate (SSG) verlieren Sie Server-Header. Cache-Control muss dann auf dem Hosting-Anbieter (Vercel, Netlify, Nginx) konfiguriert werden. Nur im SSR-Modus (nuxt build) können Sie Header per routeRules und Middleware setzen.
Cache-Control per routeRules
Definieren Sie unterschiedliche Cache-Strategien für verschiedene Routen. Statische Assets können lang gecacht werden, HTML-Seiten sollten revalidiert werden, und sensible Bereiche (Dashboard, Login, Account) dürfen nicht gecacht werden. Die routeRules in nuxt.config.ts sind die empfohlene Methode.
// nuxt.config.ts — Cache-Control per routeRules
export default defineNuxtConfig({
routeRules: {
// Statische Assets: lang cachen (Nuxt Default)
'/_nuxt/**': {
headers: {
'Cache-Control': 'public, max-age=31536000, immutable',
},
},
// HTML-Seiten: kurz cachen, revalidieren
'/**': {
headers: {
'Cache-Control': 'public, max-age=0, must-revalidate',
},
},
// Sensible Seiten: nicht cachen
'/dashboard/**': {
headers: {
'Cache-Control': 'private, no-cache, no-store, must-revalidate',
},
},
// Login und Account: nicht cachen
'/login': {
headers: {
'Cache-Control': 'private, no-cache, no-store, must-revalidate',
},
},
'/account/**': {
headers: {
'Cache-Control': 'private, no-cache, no-store, must-revalidate',
},
},
},
})Nitro Server Middleware für dynamische Logik
Für komplexere Logik — etwa Content-Hash-basiertes Caching oder Cookie-abhängige Entscheidungen — nutzen Sie eine Nitro Server Middleware. Die Middleware wird bei jedem Request ausgeführt und kann den Cache-Control-Header dynamisch setzen.
// server/middleware/cache.ts — dynamische Cache-Kontrolle
export default defineEventHandler((event) => {
const path = event.path;
// API-Routen: nie cachen
if (path.startsWith('/api/')) {
setHeader(event,
'Cache-Control',
'private, no-cache, no-store'
);
setHeader(event,
'Pragma',
'no-cache'
);
return;
}
// Statische Assets mit Hash: immutable
if (path.match(/\.[a-f0-9]{8}\./)) {
setHeader(event,
'Cache-Control',
'public, max-age=31536000, immutable'
);
}
})private erlaubt Browser-Cache, verbietet CDN/Proxy-Cache. no-store verbietet jegliches Caching. Für maximale Sicherheit auf sensiblen Routen kombinieren Sie beide: private, no-cache, no-store, must-revalidate.
nuxt-security Modul
Das nuxt-security Modul setzt keine Cache-Control-Defaults, kann aber mit routeRules kombiniert werden. Wenn Sie nuxt-security bereits für andere Security Header verwenden, definieren Sie Cache-Control weiterhin über routeRules — die beiden Ansätze ergänzen sich.
// nuxt.config.ts — nuxt-security Alternative
export default defineNuxtConfig({
modules: ['nuxt-security'],
security: {
headers: {
// nuxt-security setzt keine Cache-Control Defaults
// Nutzen Sie routeRules für Cache-Control
},
},
})Cache-Header verifizieren
Prüfen Sie die Cache-Header für verschiedene Ressourcentypen. Erstellen Sie einen Production-Build mit npx nuxi build — der Dev-Server kann andere Header setzen als der Produktiv-Build. Der Wolf-Agents Web Security Check bewertet Cache-Control mit bis zu 8 Punkten.
# Production-Build starten
npx nuxi build && node .output/server/index.mjs
# HTML-Seite
curl -sI https://ihre-domain.de | grep -i cache-control
# Erwartete Ausgabe:
# Cache-Control: public, max-age=0, must-revalidate
# Statisches Asset
curl -sI https://ihre-domain.de/_nuxt/entry.abc123.js | grep -i cache-control
# Erwartete Ausgabe:
# Cache-Control: public, max-age=31536000, immutable
# Dashboard-Seite
curl -sI https://ihre-domain.de/dashboard | grep -i cache-control
# Erwartete Ausgabe:
# Cache-Control: private, no-cache, no-store, must-revalidateHäufige Fehler
Sensible API-Daten im CDN-Cache
API-Routen ohne Cache-Control: private, no-store können in CDN-Caches landen. Ein anderer Nutzer hinter dem gleichen CDN sieht möglicherweise gecachte personenbezogene Daten. Setzen Sie private, no-store für alle authentifizierten Routen.
nuxt-security überschreibt routeRules
Wenn nuxt-security und routeRules denselben Header setzen, kann es zu Konflikten kommen. Konfigurieren Sie Cache-Control nur an einer Stelle — bevorzugt über routeRules, da diese routenspezifisch sind.
SSG-Build verliert Server-Header
nuxt generate erzeugt statische Dateien ohne Server. Cache-Control aus routeRules wird nicht angewandt. Konfigurieren Sie Cache-Control auf dem Hosting-Anbieter (Vercel, Netlify, Nginx).
Dev-Server hat andere Header
Der nuxi dev-Server setzt möglicherweise andere Cache-Header als der Production-Build. Testen Sie immer mit nuxi build und dem Production-Server. Nutzen Sie npx nuxi cleanup vor dem Build.
Compliance-Relevanz
PCI DSS fordert, dass sensible Daten nicht in öffentlichen Caches gespeichert werden — no-store auf Zahlungs- und Authentifizierungsseiten ist eine explizite Anforderung. DSGVO verlangt den Schutz personenbezogener Daten auch in Caches — gecachte Dashboard-Seiten verletzen die Datenschutzprinzipien. NIS2 fordert angemessene technische Maßnahmen zum Datenschutz. OWASP empfiehlt no-store für alle authentifizierten Responses. Der Wolf-Agents Web Security Check bewertet Cache-Control mit bis zu 8 Punkten.
Wie steht Ihre Domain bei Cache-Control?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.