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.
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.
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 — 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> 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 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 # /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 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.
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.
# 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) 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.