Cache-Control auf All-Inkl konfigurieren
Sicherheitsrelevante Cache-Direktiven auf Ihrem All-Inkl Webhosting — HTML-Seiten nicht cachen, statische Assets lang cachen mit mod_headers und mod_expires.
Cache-Control auf All-Inkl
Cache-Control steuert, wie Browser und Proxies Ihre Inhalte cachen. Aus Sicherheitsperspektive ist entscheidend: Sensible Seiten (Login, Dashboard, Checkout) dürfen nicht gecacht werden, damit veraltete oder persönliche Daten nicht aus dem Cache ausgeliefert werden. Im Wolf-Agents Web Security Check bringt Cache-Control 8 von 166 Punkten.
Auf All-Inkl sind sowohl mod_headers als auch mod_expires aktiv. Sie konfigurieren Cache-Control per .htaccess mit FilesMatch-Direktiven, um HTML-Seiten und statische Assets unterschiedlich zu behandeln.
Cache-Control auf All-Inkl implementieren
Verwenden Sie FilesMatch-Direktiven, um HTML/PHP und statische Assets unterschiedlich zu cachen. HTML-Seiten erhalten no-cache, no-store, statische Assets max-age=31536000, immutable.
# /www/htdocs/[username]/[domain]/.htaccess
# Sicherheitsrelevante Cache-Control für HTML-Seiten
<IfModule mod_headers.c>
# HTML: Nicht cachen (sensible Seiten)
<FilesMatch "\.(html|php)$">
Header set Cache-Control "no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
</FilesMatch>
# Statische Assets: Lang cachen mit Immutable
<FilesMatch "\.(js|css|woff2|png|jpg|svg|webp)$">
Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>
</IfModule>
# mod_expires für Fallback
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/html "access plus 0 seconds"
ExpiresByType text/css "access plus 1 year"
ExpiresByType application/javascript "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType font/woff2 "access plus 1 year"
</IfModule>Das immutable-Attribut teilt dem Browser mit, dass sich die Datei während der max-age-Dauer nicht ändert. Voraussetzung: Dateinamen enthalten einen Hash (z.B. app.a1b2c3.js). Ohne Hash-basierte Dateinamen verwenden Sie immutable nicht.
Verifizierung
Prüfen Sie Cache-Control-Header für HTML und statische Assets separat.
# Cache-Control für HTML prüfen
curl -sI https://ihre-domain.de | grep -i cache-control
# Cache-Control für Assets prüfen
curl -sI https://ihre-domain.de/assets/style.css | grep -i cache-control
# Erwartete Ausgabe HTML:
# cache-control: no-cache, no-store, must-revalidate
# Erwartete Ausgabe CSS:
# cache-control: public, max-age=31536000, immutableHäufige Fehler bei Cache-Control auf All-Inkl
FilesMatch Regex-Syntax falsch
Die <FilesMatch>-Direktive in der .htaccess erfordert Apache-kompatible Regex-Syntax. Häufiger Fehler: \\.(html|php) statt "\\.(html|php)$" — der abschließende $ und die Anführungszeichen sind auf All-Inkl Pflicht. Ohne korrekte Syntax greift die Regel nicht oder führt zum 500-Fehler.
CDN-Provider cached trotz no-store
Wenn Sie einen CDN-Provider (Cloudflare, Bunny.net) vor Ihrem All-Inkl-Webspace nutzen, kann das CDN trotz no-store Header cachen. Prüfen Sie die CDN-eigenen Cache-Einstellungen und konfigurieren Sie dort Cache-Bypass-Regeln für HTML-Seiten und Login-Bereiche.
CMS setzt eigene Cache-Header
WordPress und andere CMS setzen eigene Cache-Header per PHP. Die .htaccess-Einstellungen können von PHP-Headern überschrieben werden. Prüfen Sie, welche Header tatsächlich ankommen, und deaktivieren Sie ggf. CMS-eigene Caching-Einstellungen.
Compliance-Relevanz
Korrektes Caching sensibler Seiten verhindert die Offenlegung personenbezogener Daten über Browser- und Proxy-Caches.
Wie steht Ihre Domain bei Cache-Control?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.