Browsercache und gemeinsamer Cache sind verschiedene Risiken
Ein privater HTTP-Cache gehört einem einzelnen Nutzerkontext, etwa einem Browserprofil. Ein gemeinsam genutzter Cache kann Antworten für mehrere Nutzer wiederverwenden, beispielsweise ein CDN oder Reverse Proxy. Personalisierte Inhalte dürfen nicht versehentlich als öffentliche Variante an andere Personen gelangen. Auf gemeinsam benutzten Geräten bleibt zusätzlich die Frage, welche Daten innerhalb des Browserprofils zugänglich sind. RFC 9111 §§ 1–3
Ein fehlender Cache-Control-Header beweist dabei weder einen Datenabfluss noch fehlendes Caching. Je nach Status, anderen Metadaten und Cache kann eine Antwort auch ohne ausdrückliche Frist gespeichert und heuristisch als frisch behandelt werden. Öffentliches Caching ist für geeignete Inhalte sinnvoll.
Der Web Security Check liest Direktiven und erkennbare CDN-Signale der finalen Antwort. Er kennt nicht sämtliche Daten, Loginzustände und Cache-Regeln Ihrer Anwendung. Er führt weder einen Zugriff mit zwei Konten noch einen vollständigen Cache-Auslieferungstest aus. Eine Einstufung ist daher ein Hinweis zur Prüfung des Antwortkontexts.
Die Direktiven in ihrer jeweiligen Bedeutung
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Direktive | Bedeutung für konforme HTTP-Caches | Wichtige Grenze |
|---|---|---|
no-store | Betreffende Anfrage/Antwort nicht speichern und die Antwort nicht für andere Requests verwenden. | Kein allgemeines Löschkommando für frühere Kopien oder Anwendungsspeicher. |
no-cache | Speicherung erlaubt, Wiederverwendung erst nach erfolgreicher Validierung. | Der Inhalt kann bereits im Cache liegen. |
private | Gemeinsam genutzte Caches dürfen die Antwort nicht speichern; private Caches können es unter den übrigen Regeln. | Bedeutet keine Verschlüsselung und keinen Schutz vor anderen Personen im selben Browserprofil. |
public | Erlaubt ausdrücklich Caching unter den übrigen Regeln, auch in bestimmten sonst eingeschränkten Fällen. | Keine geeignete pauschale Freigabe für personalisierte Inhalte. |
max-age=N | Frischefrist in Sekunden; das bereits erreichte Alter zählt mit. | Keine Garantie, dass eine Kopie tatsächlich gespeichert wird. |
s-maxage=N | Besondere Frischefrist für gemeinsam genutzte Caches, vor max-age/Expires. | Kann auch Caching von Authorization-Antworten ermöglichen. |
must-revalidate | Nach Ablauf der Frischefrist nicht ohne erfolgreiche Validierung wiederverwenden. | Erlaubt vorherige Speicherung; nicht gleichbedeutend mit no-cache. |
immutable | Signalisiert unveränderten Inhalt während der Frischefrist; vermeidet normale unnötige Revalidierung. | Kein ewiges Caching und kein Verbot eines ausdrücklich erzwungenen Neuladens. |
Die ersten Regeln stehen in RFC 9111 § 5.2, immutable in RFC 8246 § 2. Die Tabelle verwendet private und no-cache ohne Feldliste. Qualifizierte Varianten wie private="Set-Cookie" betreffen nur benannte Headerfelder; daraus folgt kein Speicherverbot für den gesamten Inhalt.
Für ein einfaches Speicherverbot reicht Cache-Control: no-store. Zusätzliche private, no-cache und must-revalidate sind dafür nicht nötig. Kombinieren Sie Sonderdirektiven nicht mechanisch: must-understand hat beispielsweise ausdrücklich definierte Wechselwirkungen mit no-store. Pragma: no-cache ist als Antwortfeld kein verlässlich spezifizierter Ersatz für Cache-Control. RFC 9111 §§ 5.2.2.3, 5.4
Revalidierung spart Übertragung, nicht zwingend Speicherung
Bei no-cache kann ein Browser eine gespeicherte Antwort mit ihrem ETag über If-None-Match validieren. Eine passende 304 Not Modified bestätigt die Weiterverwendung der vorhandenen Darstellung; sie liefert nicht den ganzen Inhalt erneut. Zugriffskontrolle und Variantenwahl müssen dabei weiter stimmen. Ein Validator ist keine Berechtigung.
In der lokalen Probe verwendete Chromium eine frische Antwort ohne zweiten Serverabruf, validierte no-cache mit einem bedingten Request und rief no-store erneut ohne Cachevalidator ab. Das prüft diesen privaten Browsercache, kein echtes CDN.
Beispiele nach Inhalt und Verwendungszweck
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Antwort | Mögliche Einstellung | Voraussetzung |
|---|---|---|
| Persönliche Kontodaten, Reset-Informationen oder sensible API-Antwort | Cache-Control: no-store | Dieser Inhalt soll nicht im HTTP-Cache gespeichert werden. |
| Nutzerbezogene, lokal speicherbare Antwort, die vor Nutzung aktuell geprüft werden muss | Cache-Control: private, no-cache | Speicherung im privaten Cache ist akzeptiert; erfolgreiche Validierung erforderlich. |
| Öffentliche Seite mit vertretbarer Aktualisierungsverzögerung | Cache-Control: public, max-age=3600 | Keine personenbezogene Variante wird unter demselben Cacheschlüssel vermischt; eine Stunde ist eine Beispielentscheidung. |
| Öffentliches Asset mit unveränderlicher Inhaltsadresse | Cache-Control: public, max-age=31536000, immutable | Bei jeder Inhaltsänderung neue URL; alte Versionen bleiben für bestehende Dokumente verfügbar. |
Der Routenname allein entscheidet nicht. Eine öffentliche Loginhülle kann andere Anforderungen haben als die darin geladenen personenbezogenen Daten. Eine JSON-Antwort kann öffentlich oder vertraulich sein. Die Werte gelten für die jeweilige Antwort, nicht automatisch für sämtliche Unterressourcen.
Bei langen Fristen planen Sie den Rückweg vorab: Ein bereits frischer Browsercache erfährt eine neue Serverpolicy möglicherweise erst beim nächsten Abruf. Neue Asset-URLs und ein gezieltes CDN-Purge können notwendig sein; eine aktuelle no-store-Antwort entfernt nicht zuverlässig sämtliche früher gespeicherten Versionen.
Varianten, Cookies und Authorization
Vary benennt Requestheader, deren Werte bei der Wahl einer gespeicherten Variante berücksichtigt werden müssen. Vary: Accept-Encoding kann etwa komprimierte Antwortvarianten auseinanderhalten. Vary: Cookie oder Vary: Authorization sind weder eine Nutzerberechtigung noch ein Ersatz für ein beabsichtigtes Speicherverbot. RFC 9111 § 4.1
Für Anfragen mit Authorization beschränkt RFC 9111 die Wiederverwendung in gemeinsamen Caches bereits. Bestimmte Antwortdirektiven — public, s-maxage und must-revalidate — können sie unter ihren Bedingungen erlauben. Diese Regeln beziehen sich nicht automatisch auf jede Cookie-basierte Anmeldung. Auch ein Set-Cookie-Header allein ist kein universelles Speicherverbot. RFC 9111 §§ 3.5, 7.3
Prüfen Sie den tatsächlichen CDN-Schlüssel und Regeln wie „cache everything“, Query-Normalisierung und Cookie-Ausnahmen. Eine Variantenliste, die das CDN ignoriert oder anders behandelt, kann nicht durch bloßes Hinzufügen eines weiteren Headers repariert werden.
HTTP-Cache, bfcache und Service Worker getrennt prüfen
Der Back-Forward-Cache (bfcache) kann einen ganzen Dokumentzustand einschließlich JavaScript-Zustand für die Zurück-/Vorwärtsnavigation vorhalten. Das ist ein anderer Mechanismus als der HTTP-Cache. Chrome erlaubt unter bestimmten Bedingungen auch Seiten mit no-store im bfcache und berücksichtigt dabei unter anderem Änderungen an Cookies und weiteren Autorisierungssignalen. Chrome: bfcache und no-store
Eine lokale Chromium-147-Probe stellte eine no-store-Seite ohne Cookieänderung aus dem bfcache wieder her. pageshow mit event.persisted zeigte diese Wiederherstellung. Das ist ein Gegenbeleg zur Aussage „no-store verhindert jede Rückkehr zur alten Ansicht“, aber keine Abnahme eines Logoutflows. Prüfen Sie nach Abmeldung, Kontowechsel und im zweiten Tab sowohl sichtbare Inhalte als auch serverseitig wirksame Zugriffsrechte.
Die Cache API ist wiederum ein von der Anwendung steuerbarer Speicher, oft zusammen mit Service Workern. Ihr put() folgt nicht automatisch einem HTTP-Speicherverbot. Im lokalen Gegenfall konnte JavaScript eine Antwort mit no-store dort ablegen und wieder lesen. App-Offlinefunktionen und Service-Worker-Routen brauchen deshalb eigene Regeln für persönliche Daten. Service Workers: Cache.put
Eine Cacheänderung nachvollziehbar abnehmen
- Listen Sie Antworttypen und Zustände auf: öffentlich, angemeldet, abgemeldet, Fehler und Weiterleitung. Markieren Sie, welche Inhalte gespeichert oder geteilt werden dürfen.
- Prüfen Sie Ursprung, Proxy und CDN im tatsächlichen Auslieferungsweg. GET und HEAD können unterschiedlich konfiguriert sein; ein GET bildet den Inhaltsabruf besser ab.
- Prüfen Sie im isolierten Test mit synthetischen Konten A und B: warmen Cache erzeugen, anderes Konto aufrufen, Abmeldung und erneuten Zugriff testen. Kein Nutzer darf fremde Inhalte erhalten.
- Untersuchen Sie Serverzugriffe, Status,
Age, Validatoren und herstellerspezifische Cache-Statusfelder gemeinsam. Browser-DevTools mit „Cache deaktivieren“ verändert den Versuch und ist keine normale Cacheprobe. - Testen Sie Zurück/Vorwärts, offene Tabs, Offlinewege und Service Worker separat. Bereinigung über Clear-Site-Data ist eine gezielte Ergänzung mit eigenem Geltungsbereich.
Bei Web Cache Deception unterscheiden sich URL-/Routinginterpretation von Cache und Anwendung. Eine URL wie /konto/datei.css ist erst dann problematisch, wenn sie personalisierten Inhalt liefert und dieser unzulässig gespeichert beziehungsweise geteilt wird. Im eigenen Test gehören daher Routing-Gegenfälle und Inhaltsvergleich dazu; die Dateiendung oder ein einzelner Header beweist keinen Angriff.
Ein Cachebefund ist kein Rechtsurteil
Die Sicherheitsbewertung folgt dem tatsächlichen Inhalt, der Zugänglichkeit und dem Anwendungskontext. Aus fehlendem no-store allein lässt sich weder ein Datenschutzverstoß noch ein bestimmtes Bußgeld ableiten. Umgekehrt beweist der Header keine vollständige Vertraulichkeit oder NIS2-Konformität. Die Compliance-Übersicht ordnet technische Einzelmaßnahmen ein.
Häufig gestellte Fragen
Bedeutet no-cache, dass nichts gespeichert wird?
Nein. Es verlangt erfolgreiche Validierung vor Wiederverwendung. Für ein Speicherverbot der betreffenden HTTP-Antwort verwenden Sie no-store.
Ist private auf einem gemeinsam benutzten Rechner ausreichend?
Es verbietet gemeinsame HTTP-Caches, schützt aber nicht automatisch den lokalen Browserinhalt vor der nächsten Person. Prüfen Sie Speicherbedarf, Logout und Gerätegebrauch gesondert.
Muss jede authentifizierte Antwort Vary: Authorization haben?
Nein. Vary ist Variantenwahl. Die Regeln für Authorization, der Dateninhalt und die gewünschte Speicherung bestimmen gemeinsam die richtige Strategie.
Ist public grundsätzlich unsicher?
Für passende öffentliche Inhalte ist es sinnvoll. Es darf keine ungewollte gemeinsame Wiederverwendung personalisierter Antworten ermöglichen.
Quellen und technischer Stand
Quellenstand: 27.09.2026. RFC 9111 ist die aktuelle HTTP-Caching-Grundlage und ersetzt RFC 7234; die Errata wurden mit Status gelesen. RFC 8246 ergänzt immutable. Hersteller- und Service-Worker-Quellen stehen an den betreffenden Aussagen. Lokale Proben: Chromium 147.0.7727.15, privater HTTP-Cache, Cache API und gezielter bfcache-Gegenfall; kein produktiver Shared-Cache oder Kundenkonto.