Cache-Control für Vercel konfigurieren
Schritt-für-Schritt-Anleitung: Sicherheitsrelevante Cache-Direktiven auf Vercel — sensible Seiten schützen und Vercel Edge Caching richtig nutzen.
Cache-Control auf Vercel
Cache-Control steuert, wie Browser und CDNs Responses zwischenspeichern. Falsche Cache-Einstellungen können dazu führen, dass sensible Daten — Dashboard-Seiten, API-Responses — im Browser-Cache oder auf Vercels Edge Network gespeichert werden. Cache-Control ist mit 8 von 166 Punkten im Wolf-Agents Web Security Check bewertet.
Vercel betreibt ein eigenes Edge Network mit globalem Caching. Die Direktive s-maxage steuert das CDN-Caching, max-age das Browser-Caching. Für sensible Seiten müssen Sie no-store, private explizit setzen — Vercel cached Serverless Function Responses standardmäßig nicht, aber statische und ISR-Seiten schon.
Wichtig: Bei Vercel Deployments in EU-Regionen (fra1, cdg1) werden Responses auf Edge Nodes in Frankfurt und Paris gecached. Stellen Sie sicher, dass personenbezogene Daten mit private markiert sind — sonst könnte ein CDN-Node die Response für andere Nutzer ausliefern.
Cache-Control per vercel.json
Definieren Sie unterschiedliche Cache-Policies pro Pfad-Pattern in der vercel.json. Sensible Bereiche wie /dashboard erhalten no-store, damit weder Browser noch CDN die Response speichern. Statische Assets wie /_next/static erhalten immutable für maximale Performance — diese Dateien haben Content-Hashes im Dateinamen und ändern sich nie.
// vercel.json — Cache-Control für sensible Seiten
{
"headers": [
{
"source": "/dashboard/(.*)",
"headers": [
{
"key": "Cache-Control",
"value": "no-store, no-cache, must-revalidate, private"
}
]
},
{
"source": "/_next/static/(.*)",
"headers": [
{
"key": "Cache-Control",
"value": "public, max-age=31536000, immutable"
}
]
}
]
}s-maxage gilt nur für Shared Caches (Vercels Edge Network), max-age gilt für den Browser-Cache. Für öffentliche Seiten können Sie s-maxage=60 setzen, um das CDN 60 Sekunden cachen zu lassen, während der Browser mit max-age=0 immer revalidiert.
Alternative: Edge Middleware
Für dynamischere Cache-Logik — zum Beispiel basierend auf Authentication-Status oder Cookie-Werten — nutzen Sie die Edge Middleware. Die Middleware kann pro Request entscheiden, welche Cache-Policy gelten soll. Das ist besonders nützlich, wenn eingeloggte und nicht-eingeloggte Nutzer unterschiedliche Responses erhalten.
// middleware.ts — Cache-Control per Edge Middleware
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
export function middleware(request: NextRequest) {
const response = NextResponse.next();
const path = request.nextUrl.pathname;
// Sensible Seiten: Kein Caching
if (path.startsWith('/dashboard') || path.startsWith('/api')) {
response.headers.set('Cache-Control',
'no-store, no-cache, must-revalidate, private');
}
return response;
}s-maxage. Wenn Sie Cache-Control: public, s-maxage=60 setzen, wird die Response 60 Sekunden auf dem CDN gecached — auch personalisierte Inhalte. Verwenden Sie private für nutzerspezifische Seiten. Cache-Header verifizieren
Prüfen Sie die Cache-Control-Header für verschiedene Seitentypen nach dem Deployment. Achten Sie zusätzlich auf den x-vercel-cache-Header — er zeigt, ob die Response vom CDN-Cache (HIT) oder vom Origin (MISS) kommt. Der Wolf-Agents Web Security Check analysiert, ob sensible Seiten korrekt mit no-store geschützt sind.
# Cache-Control für Dashboard prüfen
curl -sI https://ihre-domain.de/dashboard | grep -i cache-control
# Erwartete Ausgabe:
cache-control: no-store, no-cache, must-revalidate, private
# Cache-Control für statische Assets prüfen
curl -sI https://ihre-domain.de/_next/static/chunks/main.js | grep -i cache-control
# Erwartete Ausgabe:
cache-control: public, max-age=31536000, immutable
# Vercel x-vercel-cache Header zeigt CDN-Status
curl -sI https://ihre-domain.de | grep -i x-vercel-cache
# Mögliche Werte: MISS, HIT, STALE, PRERENDERHäufige Fehler
Vercel CDN cached sensible Daten
Wenn Sie s-maxage für Seiten mit persönlichen Daten setzen, cached das Edge Network die Response für alle Nutzer. Verwenden Sie private, no-store für Dashboard-Seiten und API-Endpoints mit Nutzerdaten.
Framework-Cache überschreibt vercel.json
Next.js setzt eigene Cache-Header für statische und dynamische Seiten. Diese haben Vorrang vor vercel.json. Prüfen Sie die tatsächlichen Header im Browser, nicht nur die Konfiguration.
Cache nicht invalidiert nach Deployment
Vercels Edge Network invalidiert den Cache nicht automatisch bei Header-Änderungen in vercel.json. Erst ein neues Deployment mit neuen Assets oder eine manuelle Invalidierung über das Vercel Dashboard löscht gecachte Responses.
Preview Deployment cached Produktiv-Daten
Preview Deployments auf *.vercel.app teilen sich nicht den Cache mit der Produktiv-Domain. Trotzdem sollten Sie sensible API-Responses auch auf Preview URLs mit no-store schützen — QA-Teams testen dort mit echten Daten.
Compliance-Relevanz
Korrekte Cache-Einstellungen schützen sensible Daten. DSGVO fordert technische Maßnahmen zum Schutz personenbezogener Daten — gecachte Login-Seiten auf öffentlichen Geräten sind ein Datenschutz-Risiko. PCI DSS verlangt, dass Zahlungsdaten nicht gecached werden. Der Wolf-Agents Web Security Check bewertet Cache-Control im Sicherheitskontext und erkennt fehlende no-store-Direktiven auf authentifizierten Seiten.
Wie steht Ihre Domain bei Cache-Control?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.