Cache-Control für Express.js konfigurieren

Schritt-für-Schritt-Anleitung: Custom Middleware für API-Endpunkte und Login, express.static für statische Assets mit immutable, und Clear-Site-Data beim Logout — mit fertigen Code-Beispielen.

Cache-Konfiguration prüfen Plattform entdecken
Express.js · Schritt für Schritt
Von Wolf-Agents Security Team · Aktualisiert: 26. März 2026

Cache-Control in Express.js einrichten

Express.js setzt standardmäßig keine Cache-Control-Header für dynamische Routen — der Browser entscheidet eigenständig. Für Produktionsanwendungen müssen Sie Cache-Control explizit über Custom Middleware oder Route-Handler setzen.

Diese Anleitung zeigt vier Schritte: Custom Middleware für sensible Endpunkte, optimale express.static-Konfiguration für statische Assets, Clear-Site-Data beim Logout und Verifizierung der Konfiguration.

Einführung in Cache-Control-Sicherheit

1 Schritt 1 von 4

Custom Middleware für no-store erstellen

Erstellen Sie eine wiederverwendbare Middleware-Funktion, die Cache-Control: no-store setzt. Mit app.use() können Sie sie selektiv auf bestimmte Routen anwenden — ohne alle Route Handler einzeln anzupassen.

middleware/cache-control.js Middleware 
// middleware/cache-control.js — Custom Cache-Control Middleware
const noCacheHeaders = (req, res, next) => {
  res.set({
    'Cache-Control': 'no-store',
    'Pragma': 'no-cache',
    'Expires': '0'
  });
  next();
};

const privateCache = (req, res, next) => {
  res.set('Cache-Control', 'private, no-cache, must-revalidate');
  next();
};

// Routen-spezifische Anwendung
app.use('/api', noCacheHeaders);
app.use('/login', noCacheHeaders);
app.use('/assets', express.static('public', { maxAge: '1y', immutable: true }));
Reihenfolge der Middleware beachten

In Express.js wird Middleware in der Reihenfolge ausgeführt, in der sie registriert wird. Stellen Sie sicher, dass noCacheHeaders vor dem Route Handler registriert wird, der die Response sendet.

2 Schritt 2 von 4

express.static für optimales Asset-Caching konfigurieren

express.static akzeptiert eine options-Objekt, mit dem Sie maxAge und immutable konfigurieren können. Versionierte Assets — JavaScript-Bundles und CSS-Dateien mit Content-Hash im Dateinamen — können dauerhaft gecacht werden.

app.js Static Assets 
// app.js — Statische Assets mit immutable cachen
const path = require('path');
const express = require('express');

// Versionierte Assets: dauerhaft cachen
app.use('/assets', express.static(path.join(__dirname, 'public/assets'), {
  maxAge: '1y',
  immutable: true,
  etag: false
}));

// Uploads: kürzere TTL (Inhalte können sich ändern)
app.use('/uploads', express.static(path.join(__dirname, 'uploads'), {
  maxAge: '7d'
}));
etag: false für dauerhaft gecachte Assets: ETags verursachen unnötige Revalidierungsanfragen, obwohl der Asset sich nie ändert. Bei immutable-Assets sind ETags überflüssig.
3 Schritt 3 von 4

Clear-Site-Data beim Logout senden

Der Clear-Site-Data-Header weist den Browser an, beim Logout alle gecachten Ressourcen zu löschen. Das ist besonders wichtig auf gemeinsam genutzten Geräten, wo ein anderer Nutzer nach dem Logout noch gecachte personalisierte Seiten aufrufen könnte.

routes/auth.js Logout 
// routes/auth.js — Logout mit Clear-Site-Data
app.post('/logout', (req, res) => {
  // Session zerstören
  req.session.destroy((err) => {
    if (err) console.error(err);
  });

  // Browser-Cache leeren
  res.setHeader('Clear-Site-Data', '"cache"');
  res.setHeader('Cache-Control', 'no-store');

  res.redirect('/login');
});
Clear-Site-Data wird von Safari nicht unterstützt. Für vollständige Browser-Kompatibilität sollten Sie zusätzlich Cache-Control: no-store auf allen personalisierten Seiten setzen — damit können Safari-Nutzer gecachte Inhalte nach dem Logout nicht mehr aufrufen.
4 Schritt 4 von 4

Konfiguration verifizieren

Nach der Implementierung prüfen Sie, ob alle Cache-Control-Header korrekt gesetzt werden. Nutzen Sie curl für einen schnellen Check und die Browser DevTools (Network-Tab → Response Headers) für eine visuelle Prüfung.

Terminal Verifizierung 
# API-Endpunkt prüfen
curl -sI https://ihre-domain.de/api/user | grep -i cache-control
# Erwartete Ausgabe: Cache-Control: no-store

# Login-Seite prüfen
curl -sI https://ihre-domain.de/login | grep -i cache-control
# Erwartete Ausgabe: Cache-Control: no-store

# Statische Assets prüfen
curl -sI https://ihre-domain.de/assets/main.abc123.js | grep -i cache-control
# Erwartete Ausgabe: Cache-Control: public, max-age=31536000, immutable
Wolf-Agents Scanner als Alternative

Der Wolf-Agents Web Security Check prüft automatisch, ob Cache-Control für sensible Bereiche korrekt konfiguriert ist — als Teil der 166 Prüfpunkte mit 8 Punkten für Cache-Control.

Auch verfügbar für:

NginxApacheWordPressNext.jsCloudflareCaddyShopifyDemnächst

Wie steht Ihre Domain bei Cache-Control?

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

Web Security Check starten Monitoring ab 199 EUR/Mo

Häufig gestellte Fragen

Wie setze ich Cache-Control in Express.js?

In Express.js setzen Sie Cache-Control über res.set() oder res.setHeader() in Route Handlern, oder über Middleware mit next(). Die einfachste Methode ist eine Custom Middleware: const noCacheHeaders = (req, res, next) => { res.set("Cache-Control", "no-store"); next(); }; die Sie mit app.use("/api", noCacheHeaders) an bestimmte Routen binden.

Setzt Express.js standardmäßig Cache-Control-Header?

Ja, aber nicht immer korrekt: express.static setzt für Dateien automatisch Cache-Control: public, max-age=0 (ohne maxAge-Option). Für dynamische Routen setzt Express keine Cache-Control-Header — der Browser entscheidet selbst über Caching. Für Produktionsumgebungen müssen Sie Cache-Control für alle sensiblen Routen explizit setzen.

Wie nutze ich helmet.js für Cache-Control?

helmet.js setzt standardmäßig den Header Cache-Control: no-store für alle Routen, auf die es angewendet wird. Das ist zu restriktiv für öffentliche Seiten und statische Assets. Verwenden Sie helmet() selektiv: app.use("/api", helmet()), und konfigurieren Sie statische Assets separat mit express.static.

Wie konfiguriere ich express.static für optimales Caching?

express.static akzeptiert eine options-Objekt: app.use("/assets", express.static("public", { maxAge: "1y", immutable: true, etag: false })). maxAge: "1y" entspricht 31536000 Sekunden. immutable: true fügt den immutable-Keyword hinzu. etag: false deaktiviert ETags für dauerhaft gecachte Assets.

Was ist Clear-Site-Data und wie implementiere ich es in Express?

Clear-Site-Data ist ein HTTP-Header, der den Browser anweist, bestimmte Daten zu löschen. Clear-Site-Data: "cache" löscht alle gecachten Ressourcen. In Express: app.post("/logout", (req, res) => { req.session.destroy(); res.setHeader("Clear-Site-Data", ""cache""); res.redirect("/login"); });. Unterstützt in allen modernen Browsern außer Safari.