Cache-Control für LiteSpeed konfigurieren

Schritt-für-Schritt-Anleitung: Sicherheitsrelevante Cache-Direktiven auf LiteSpeed — .htaccess, LSCache-Kompatibilität und no-store für sensible Seiten.

LiteSpeed · Schritt für Schritt

Cache-Control auf LiteSpeed

Cache-Control steuert, wie Browser und Proxies Responses zwischenspeichern. Für die Sicherheit ist entscheidend, dass sensible Seiten (Login, Dashboard, Kontodaten) nie gecached werden — weder vom Browser noch von Proxies oder dem LiteSpeed-eigenen LSCache.

Der größte Fallstrick auf LiteSpeed: LSCache überschreibt Cache-Control-Header. Selbst wenn Sie no-store per .htaccess setzen, kann LSCache die Seite trotzdem cachen und ausliefern. Sie müssen LSCache für sensible Pfade über den speziellen X-LiteSpeed-Cache-Control-Header explizit deaktivieren. Der Wolf-Agents Web Security Check bewertet Cache-Control mit bis zu 8 Punkten.

1 Schritt 1 von 3

Cache-Control per .htaccess

Setzen Sie Cache-Direktiven pro Dateityp. Sensible dynamische Seiten erhalten no-store, statische Assets erhalten lange Cache-Zeiten mit immutable. Das private-Keyword verhindert, dass Shared Proxies die Antwort cachen.

.htaccess Cache-Direktiven
# .htaccess — Sicherheitsrelevante Cache-Direktiven
<IfModule mod_headers.c>
    # Sensible Seiten: Kein Caching
    <FilesMatch "\.(php)$">
        Header always set Cache-Control "no-store, no-cache, must-revalidate, private"
        Header always set Pragma "no-cache"
    </FilesMatch>

    # Statische Assets: Lange Cache-Zeit mit Immutable
    <FilesMatch "\.(js|css|woff2|png|jpg|webp|avif|svg)$">
        Header always set Cache-Control "public, max-age=31536000, immutable"
    </FilesMatch>

    # HTML: Kurze Cache-Zeit
    <FilesMatch "\.html?$">
        Header always set Cache-Control "public, max-age=3600, must-revalidate"
    </FilesMatch>
</IfModule>
2 Schritt 2 von 3

LSCache für sensible Pfade deaktivieren

LSCache ist der leistungsstärkste Vorteil von LiteSpeed, kann aber die Sicherheit gefährden, wenn sensible Seiten gecached werden. Deaktivieren Sie LSCache für Login-, Dashboard- und Konto-Seiten über den X-LiteSpeed-Cache-Control-Header oder die Web Admin Console unter Virtual Hosts > [vhost] > Cache > Do-Not-Cache URLs.

.htaccess — LSCache-Kontrolle Wichtig
# .htaccess — LSCache für sensible Pfade deaktivieren
# WICHTIG: LSCache überschreibt Cache-Control!

<IfModule LiteSpeed>
    # LSCache für Login-/Dashboard-Seiten deaktivieren
    RewriteEngine On
    RewriteRule ^(login|dashboard|account)/ - [E=Cache-Control:no-cache]

    # Per X-LiteSpeed-Cache-Control Header (bevorzugt)
    <LocationMatch "^/(login|dashboard|account)/">
        Header always set X-LiteSpeed-Cache-Control "no-cache"
    </LocationMatch>
</IfModule>

# Web Admin Console Alternative:
# Server Config > Virtual Hosts > [vhost] > Cache
# Do-Not-Cache URLs: /login, /dashboard, /account
vhconf.conf Eigener Server
# /usr/local/lsws/conf/vhosts/example/vhconf.conf
# Cache-Direktiven pro Context

context / {
  type                    NULL
  location                $DOC_ROOT/

  extraHeaders {
    Header always set Cache-Control "public, max-age=3600, must-revalidate"
  }
}

# Sensible Pfade: Kein Caching
context /login {
  type                    NULL
  location                $DOC_ROOT/login

  extraHeaders {
    Header always set Cache-Control "no-store, no-cache, must-revalidate, private"
    Header always set X-LiteSpeed-Cache-Control "no-cache"
  }
}
LSCache vs. Browser-Cache

LSCache ist ein serverseitiger Cache — er speichert fertig gerenderte Seiten auf dem Server. Cache-Control: no-store kontrolliert nur den Browser-Cache. Für vollständigen Schutz benötigen Sie beide: Cache-Control: no-store für den Browser und X-LiteSpeed-Cache-Control: no-cache für LSCache.

3 Schritt 3 von 3

Konfiguration testen und verifizieren

Prüfen Sie Cache-Control-Header für verschiedene Ressourcentypen nach dem Graceful Restart. Achten Sie besonders auf sensible Seiten — dort muss no-store erscheinen. Der Wolf-Agents Web Security Check verifiziert Cache-Control automatisch als Teil der 166 Prüfpunkte.

Terminal Verifizierung
# 1. Graceful Restart (LiteSpeed cached .htaccess!)
/usr/local/lsws/bin/lswsctrl restart

# 2. Cache-Control für HTML prüfen
curl -sI https://ihre-domain.de | grep -i cache-control
# Cache-Control: public, max-age=3600, must-revalidate

# 3. Cache-Control für sensible Seiten prüfen
curl -sI https://ihre-domain.de/login | grep -i cache-control
# Cache-Control: no-store, no-cache, must-revalidate, private

# 4. Statische Assets prüfen
curl -sI https://ihre-domain.de/app.js | grep -i cache-control
# Cache-Control: public, max-age=31536000, immutable

# 5. LSCache-Status prüfen
curl -sI https://ihre-domain.de | grep -i x-litespeed
# X-LiteSpeed-Cache: hit (oder miss bei erstem Request)
Testen Sie nach dem Leeren des LSCache mit dem ersten Request — der X-LiteSpeed-Cache-Header zeigt miss beim ersten Aufruf und hit bei nachfolgenden. Bei sensiblen Seiten sollte der Header fehlen oder miss bleiben.

Häufige Fehler bei Cache-Control auf LiteSpeed

Diese LiteSpeed-spezifischen Fehler treten bei der Cache-Konfiguration am häufigsten auf und können sensible Daten im Cache exponieren.

LSCache überschreibt Cache-Control

Das häufigste Problem: LSCache setzt eigene Cache-Header. Nutzen Sie X-LiteSpeed-Cache-Control: no-cache für sensible Pfade zusätzlich zum normalen Cache-Control: no-store.

.htaccess cached — Änderungen nicht aktiv

LiteSpeed cached .htaccess. Nach Änderungen an Cache-Direktiven ist ein Graceful Restart nötig: /usr/local/lsws/bin/lswsctrl restart

Plesk LiteSpeed-Plugin hat eigene Cache-Regeln

Das Plesk LiteSpeed-Plugin konfiguriert LSCache eigenständig. Manuelle Cache-Regeln können beim nächsten Plugin-Update überschrieben werden. Nutzen Sie das Plugin-Interface für Ausnahmen.

no-cache statt no-store für Login-Seiten

no-cache erlaubt Caching mit Revalidierung — der Browser speichert die Seite trotzdem auf der Festplatte. Für Login-/Dashboard-Seiten ist no-store zwingend erforderlich.

LSCache cached Seiten mit Set-Cookie

Standardmäßig schließt LSCache Seiten mit Set-Cookie-Headern aus. Wenn Sie LSCache-Regeln anpassen, achten Sie darauf, dass Login-Responses nie gecached werden.

Web Admin Console überschreibt .htaccess

Cache-Einstellungen in der Web Admin Console (Port 7080) unter Virtual Hosts > Cache haben Vorrang über .htaccess. Prüfen Sie beide Konfigurationen auf Konflikte.

Compliance-Relevanz

PCI DSS 4.0 (Anforderung 6.5.4) fordert, dass sensible Daten nicht im Cache gespeichert werden — Cache-Control mit no-store erfüllt diese Anforderung. DSGVO erfordert technische Maßnahmen zum Schutz personenbezogener Daten — Cache-Control verhindert die Speicherung in Shared Caches und Browser-Caches. NIS2 verlangt Datenschutz bei der Übertragung und Speicherung. BSI IT-Grundschutz (APP.3.1) empfiehlt die Kontrolle von Cache-Verhalten für sensible Daten. 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.

Häufig gestellte Fragen

Überschreibt LSCache meine Cache-Control Header?

Ja. LSCache setzt eigene Cache-Control-Direktiven, die .htaccess-Einstellungen überschreiben können. Konfigurieren Sie Cache-Control für dynamische Seiten in der LSCache-Konfiguration oder deaktivieren Sie LSCache für bestimmte Pfade per X-LiteSpeed-Cache-Control: no-cache.

Wie setze ich no-store für Login-Seiten auf LiteSpeed?

Per .htaccess mit einer FilesMatch- oder LocationMatch-Direktive. Zusätzlich müssen Sie LSCache für diese Seiten per X-LiteSpeed-Cache-Control deaktivieren, da LSCache den Response sonst trotzdem cached.

Was ist der Unterschied zwischen no-cache und no-store?

no-cache erlaubt Caching, erfordert aber Revalidierung bei jedem Request. no-store verbietet Caching komplett — der Browser speichert die Antwort nicht. Für sensible Seiten (Login, Dashboard) verwenden Sie no-store.

Funktioniert Cache-Control mit QUIC/HTTP3 auf LiteSpeed?

Ja. Cache-Control-Header werden über alle Protokolle gesendet — HTTP/1.1, HTTP/2 und QUIC/HTTP3. Der Browser wertet die Direktiven unabhängig vom Transportprotokoll aus.