Cache-Control für Sicherheit: Sensible Daten schützen
Falsch konfiguriertes Caching gibt sensible Benutzerdaten an unbefugte Dritte weiter. Cache-Control: no-store ist die erste Verteidigungslinie für Login-Seiten, Dashboards und APIs.
Warum Cache-Control sicherheitsrelevant ist
HTTP-Caching beschleunigt Webanwendungen erheblich — aber falsch konfiguriert gibt es sensible Nutzerdaten an unbefugte Dritte weiter. Wenn ein Browser, Proxy oder CDN eine Seite mit Kontoständen, persönlichen Daten oder Sitzungsinformationen speichert, kann der nächste Nutzer auf demselben Gerät oder die nächste Person hinter demselben CDN diese Daten einsehen.
Der gefährlichste Angriff auf fehlkonfiguriertes Caching ist Web Cache Deception: Ein Angreifer ruft eine URL wie /dashboard/konto.css auf — CDNs und Proxys interpretieren die .css-Endung als statisches Asset und cachen die Antwort. Jeder weitere Nutzer, der dieselbe URL aufruft, erhält die gecachte Antwort des ersten Nutzers — einschließlich aller persönlichen Daten. Der Wolf-Agents Web Security Check bewertet Cache-Control als Teil der 166 Prüfpunkte mit 8 Punkten.
Cache-Control-Direktiven verstehen
Cache-Control ist ein HTTP-Response-Header mit mehreren Direktiven, die steuern, wer eine Antwort cachen darf, wie lange und unter welchen Bedingungen. Die Wahl der richtigen Direktiven hängt davon ab, ob der Inhalt personalisiert, sensibel oder öffentlich ist.
| Direktive | Bedeutung | Anwendungsfall |
|---|---|---|
no-store | Kein Speichern — weder Browser noch Proxy | Login, Dashboard, Finanzdaten, API mit Nutzerdaten |
no-cache | Speichern erlaubt, aber Revalidierung nötig | Häufig wechselnde Inhalte, Newsfeeds |
private | Nur Browser-Cache erlaubt, kein CDN/Proxy | Personalisierte, aber weniger sensible Seiten |
public | Alle Caches erlaubt (CDN, Proxy, Browser) | Statische Assets, öffentliche Seiten |
max-age=N | Cache-Gültigkeit in Sekunden | Statische Assets (z.B. max-age=31536000) |
immutable | Kein Revalidierungsversuch beim Refresh | Assets mit Content-Hash im Dateinamen |
must-revalidate | Abgelaufener Cache darf nicht ohne Revalidierung genutzt werden | Kritische Ressourcen mit Ablaufdatum |
Caching-Strategie nach Seitentyp
Die richtige Cache-Control-Strategie hängt vom Seitentyp ab. Eine einheitliche Konfiguration ist falsch — zu restriktives Caching verlangsamt die Anwendung, zu liberales Caching gibt sensible Daten preis. Hier sind die empfohlenen Einstellungen für die wichtigsten Seitentypen:
Login & Passwort-Seiten
Cache-Control: no-store Absolut kein Caching. Login-Seiten können nach Logout noch im Cache sein und erneut aufgerufen werden.
Dashboard & Profil-Seiten
Cache-Control: no-store Personalisierte Inhalte dürfen nicht von geteilten Caches gespeichert werden. Web Cache Deception-Schutz.
Authenticated API-Antworten
Cache-Control: no-store API-Endpunkte, die nutzerspezifische Daten zurückgeben, dürfen niemals gecacht werden.
Öffentliche Seiten (Homepage, Blog)
Cache-Control: public, max-age=3600 Öffentliche Inhalte ohne Nutzerdaten können frei gecacht werden. Kurze TTL für Aktualität.
Statische Assets mit Content-Hash
Cache-Control: public, max-age=31536000, immutable Versionierte Assets (main.abc123.js) können dauerhaft gecacht werden. Bei Änderung ändert sich der Hash.
Warum der Vary-Header für Cache-Isolation entscheidend ist
Der Vary-Header teilt Caches mit, welche Request-Header für die Cache-Entscheidung berücksichtigt werden müssen. Ohne Vary: Cookie oder Vary: Authorization könnte ein CDN eine authentifizierte Antwort an einen nicht authentifizierten Nutzer ausliefern — ein schwerwiegender Datenschutzverstoß.
Vary: Cookie
Erzwingt separate Cache-Einträge für jede Cookie-Kombination. Wichtig für alle Seiten, die anhand von Cookies personalisiert werden (Session-Cookies, Sprachpräferenzen).
Vary: Cookie Vary: Authorization
Separate Cache-Einträge pro Authorization-Header. Pflicht für API-Endpunkte mit Bearer-Token-Authentifizierung, um nutzerspezifische Caches zu isolieren.
Vary: Authorization Vary: Accept-Encoding
Separate Caches für komprimierte und unkomprimierte Antworten. Verhindert, dass Brotli-komprimierte Antworten an Clients ohne Brotli-Support ausgeliefert werden.
Vary: Accept-Encoding Cache-Control: no-store für sensible Seiten setzen, ist Vary dort nicht relevant — der Cache wird gar nicht erst genutzt. Vary ist entscheidend für öffentliche oder private-gecachte Seiten, die dennoch nutzerspezifisch sein können. NIS2, DSGVO und OWASP — Anforderungen an Caching
Cache-Control ist kein reines Performance-Thema. NIS2 Art. 21 Abs. 2 lit. e fordert Sicherheit bei der Wartung von Systemen — dazu gehört die korrekte Konfiguration von Caching-Headern. DSGVO Art. 32 verlangt technische Maßnahmen zum Schutz personenbezogener Daten. Fehlendes no-store auf authentifizierten Seiten kann direkt zu Bußgeldern nach DSGVO Art. 83 führen.
OWASP A05:2021
Security Misconfiguration — fehlendes oder falsches Caching ist explizit als Sicherheitsfehlkonfiguration gelistet. OWASP empfiehlt Cache-Control: no-store für alle Antworten mit sensiblen Daten.
DSGVO Art. 32
Technische Maßnahmen zur Sicherheit der Verarbeitung: Vertraulichkeit und Integrität personenbezogener Daten. Caching ohne no-store auf Seiten mit personenbezogenen Daten verletzt den Grundsatz der Vertraulichkeit.
NIS2 Art. 21 Abs. 2 lit. e
Sicherheit bei Erwerb, Entwicklung und Wartung von Systemen — Cache-Konfiguration gehört zur Systemhärtung. Im deutschen §30 Abs. 2 Nr. 5 BSIG (NIS2UmsuCG, seit 06.12.2025) konkretisiert.
BSI IT-Grundschutz
Maßnahme CON.1 — Kryptokonzept und Datenschutz: Session-Daten und personenbezogene Informationen müssen vor unberechtigtem Zugriff geschützt werden. Caching-Header sind Teil der technischen Schutzmaßnahmen.
Wie steht Ihre Domain bei Cache-Control?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 166 Prüfpunkte.
Häufig gestellte Fragen
Was ist der Unterschied zwischen no-store und no-cache?
no-store verhindert jedes Speichern der Antwort — weder Browser noch Proxys dürfen die Daten cachen. no-cache erlaubt das Speichern, aber nur nach Revalidierung beim Server. Für sensible Inhalte (Login-Seiten, Dashboards, API-Antworten mit Nutzerdaten) ist no-store die richtige Wahl. no-cache eignet sich für Inhalte, die sich oft ändern, aber kurz gecacht werden dürfen.
Was ist Web Cache Deception und wie schützt Cache-Control dagegen?
Bei Web Cache Deception ruft ein Angreifer eine URL wie /dashboard/profil.css auf — der Cache speichert die Antwort als statisches Asset, obwohl sie sensible Benutzerdaten enthält. Schutz: Für alle dynamischen und personalisierten Routen Cache-Control: no-store setzen, unabhängig von der Dateiendung in der URL.
Sollte ich Cache-Control: private oder no-store für mein Dashboard verwenden?
private verhindert, dass geteilte Caches (CDNs, Proxys) die Antwort speichern — der Browser-Cache darf sie jedoch behalten. Für hochsensible Seiten (Finanzdaten, Gesundheitsdaten, Passwortseiten) ist no-store besser: kein Speichern, nirgends. private ist ausreichend für personalisierte, aber weniger sensible Inhalte.
Warum ist der Vary-Header sicherheitsrelevant?
Ohne Vary: Authorization oder Vary: Cookie kann ein CDN für verschiedene Nutzer dieselbe gecachte Antwort ausliefern. Wenn Nutzer A eine API-Antwort abruft, könnte Nutzer B ohne richtigen Vary-Header dieselbe gecachte Antwort bekommen — inklusive der Daten von Nutzer A. Vary: Cookie, Authorization sorgt für nutzerspezifische Cache-Einträge.
Was sagt die DSGVO zu Caching?
DSGVO Art. 32 fordert technische Maßnahmen zum Schutz personenbezogener Daten. Wenn Antworten mit personenbezogenen Daten gecacht werden, ohne dass ein anderer Nutzer diese einsehen kann, verletzt das den Grundsatz der Vertraulichkeit. Cache-Control: no-store für alle Seiten mit personenbezogenen Daten ist ein direkter DSGVO-Compliance-Faktor.
Wie konfiguriere ich Cache-Control für statische Assets richtig?
Statische Assets (JS, CSS, Bilder) mit Content-Hash im Dateinamen: Cache-Control: public, max-age=31536000, immutable. Assets ohne Hash (z.B. logo.png): Cache-Control: public, max-age=86400. Das immutable-Keyword verhindert unnötige Revalidierungsanfragen, weil dem Browser signalisiert wird, dass sich der Inhalt nie ändern wird.
Prüft der Wolf-Agents Scanner Cache-Control?
Ja. Der Wolf-Agents Web Security Check bewertet Cache-Control als Teil der 166 Prüfpunkte (8 Punkte). Der Scanner prüft, ob sensible Bereiche (Login, Dashboard, API) kein öffentliches Caching erlauben und ob statische Assets für optimale Performance gecacht werden.