Cache-Control für IIS konfigurieren
Schritt-für-Schritt-Anleitung: Sicherheitsrelevante Cache-Direktiven in IIS — clientCache für Assets, no-store für sensible Bereiche und Output Caching absichern.
Cache-Control in IIS
Cache-Control bestimmt, ob und wie Browser Ressourcen zwischenspeichern. Mit 8 von 166 Punkten im Wolf-Agents Web Security Check ist die korrekte Cache-Konfiguration sicherheitsrelevant: Sensible Daten dürfen nicht im Browser-Cache oder auf Proxy-Servern gespeichert werden.
IIS bietet zwei Cache-Konfigurationen: clientCache unter staticContent für statische Dateien (CSS, JS, Bilder) und customHeaders für dynamische Seiten. Die Herausforderung: Statische Assets sollen lange gecached werden, während Login-Seiten und geschützte Bereiche no-store benötigen.
IIS unterstützt verschachtelte web.config-Dateien — Sie können verschiedene Cache-Strategien für verschiedene Verzeichnisse definieren. Das ist ideal für die Trennung von öffentlichen Assets und geschützten Bereichen.
clientCache für statische Assets
Setzen Sie clientCache mit langem max-age für statische Dateien. IIS setzt dann automatisch Cache-Control: max-age=31536000 für alle statischen Ressourcen. Verwenden Sie Content-Hashes in Dateinamen für Cache-Busting bei Updates.
<!-- web.config — Cache-Control für statische Assets -->
<configuration>
<system.webServer>
<!-- Globale Cache-Einstellung für statische Dateien -->
<staticContent>
<clientCache
cacheControlMode="UseMaxAge"
cacheControlMaxAge="365.00:00:00" />
</staticContent>
</system.webServer>
</configuration> # PowerShell — Cache-Control konfigurieren
$sitePath = 'MACHINE/WEBROOT/APPHOST/Default Web Site'
# Statische Assets: 1 Jahr Cache
Set-WebConfigurationProperty -pspath $sitePath \
-filter "system.webServer/staticContent/clientCache" \
-name "cacheControlMode" \
-value "UseMaxAge"
Set-WebConfigurationProperty -pspath $sitePath \
-filter "system.webServer/staticContent/clientCache" \
-name "cacheControlMaxAge" \
-value "365.00:00:00"
# no-store Header für sensible Bereiche
Add-WebConfigurationProperty -pspath $sitePath \
-filter "system.webServer/httpProtocol/customHeaders" \
-name "." -value @{
name = 'Cache-Control'
value = 'no-cache, no-store, must-revalidate'
}
Write-Host "Cache-Control konfiguriert." no-store für sensible Seiten
Login-Seiten, Dashboard-Bereiche und Seiten mit personenbezogenen Daten müssen no-store verwenden. Legen Sie eine separate web.config im geschützten Verzeichnis an — IIS verarbeitet web.config-Dateien hierarchisch, die Kind-Konfiguration überschreibt die Eltern.
<!-- web.config — no-store für sensible Seiten -->
<!-- In einem geschützten Unterverzeichnis (z.B. /dashboard/) -->
<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Cache-Control"
value="no-cache, no-store, must-revalidate" />
<add name="Pragma"
value="no-cache" />
<add name="Expires"
value="0" />
</customHeaders>
</httpProtocol>
<!-- Auch clientCache deaktivieren -->
<staticContent>
<clientCache
cacheControlMode="DisableCache" />
</staticContent>
</system.webServer>
</configuration> ASP.NET Core Output Caching absichern
Das ASP.NET Core Output Caching kann serverseitig Seiten cachen und an verschiedene Benutzer ausliefern. Für geschützte Bereiche müssen Sie Output Caching explizit deaktivieren. Nutzen Sie VaryByHeader für Authorization-Header, damit verschiedene Benutzer unterschiedliche Inhalte erhalten.
// ASP.NET Core — Output Caching absichern
// Program.cs
builder.Services.AddOutputCache(options =>
{
// Standard: 60 Sekunden Cache
options.AddBasePolicy(builder =>
builder.Expire(TimeSpan.FromSeconds(60)));
// Geschützte Bereiche: Kein Cache
options.AddPolicy("NoCache", builder =>
builder.NoCache());
// API: VaryByHeader für unterschiedliche Benutzer
options.AddPolicy("VaryByAuth", builder =>
builder.SetVaryByHeader("Authorization")
.Expire(TimeSpan.FromSeconds(30)));
});
// Auf Endpunkten anwenden
app.MapGet("/dashboard", () => ...)
.CacheOutput("NoCache"); Cache-Header verifizieren
Prüfen Sie die Cache-Header für verschiedene Ressourcenarten: Statische Dateien sollen lange gecached werden, HTML-Seiten sollen revalidiert werden, und sensible Seiten sollen nicht gecached werden. Der Wolf-Agents Web Security Check prüft Cache-Control automatisch.
# PowerShell — Cache-Header verifizieren
# Statisches Asset prüfen (langes Caching erwartet)
curl -sI https://ihre-domain.de/css/style.css |
Select-String "Cache-Control"
# Erwartet: Cache-Control: max-age=31536000
# Sensible Seite prüfen (kein Caching erwartet)
curl -sI https://ihre-domain.de/dashboard |
Select-String "Cache-Control|Pragma"
# Erwartet: Cache-Control: no-cache, no-store, must-revalidate
# Erwartet: Pragma: no-cache
# HTML-Seiten prüfen (kurzes Caching/Revalidierung)
curl -sI https://ihre-domain.de/ |
Select-String "Cache-Control|ETag" Häufige Fehler
clientCache und customHeaders kollidieren
Wenn clientCache und ein Cache-Control customHeader gleichzeitig gesetzt sind, sendet IIS beide — der Browser verwendet den letzten. Verwenden Sie nur eine Methode pro Ressourcentyp und nutzen Sie verschachtelte web.config-Dateien.
IIS Output Caching speichert sensible Daten
Das IIS-Kernmodul Output Caching kann serverseitig sensible Seiten cachen und an andere Benutzer ausliefern. Deaktivieren Sie Output Caching für geschützte Bereiche oder verwenden Sie varyByHeader für Authorization.
Veraltete Assets nach Deployment
Bei langem max-age ohne Content-Hash im Dateinamen liefern Browser veraltete Assets. Verwenden Sie Dateinamen mit Hash (z.B. style.abc123.css) oder query-basiertes Cache-Busting (?v=2).
Shared Hosting überschreibt Cache-Header
Auf Shared-Hosting-Umgebungen kann die applicationHost.config globale Cache-Einstellungen erzwingen. Prüfen Sie mit curl, ob Ihre web.config-Werte tatsächlich gesendet werden, oder ob der Hoster sie überschreibt.
Compliance-Relevanz
PCI DSS 4.0 fordert den Schutz sensibler Daten — unsichere Cache-Header können dazu führen, dass Zahlungsinformationen im Browser-Cache verbleiben. DSGVO Artikel 32 verlangt technische Maßnahmen zum Datenschutz. 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.