Kann Ihr CDN eine eingeloggte Seite cachen?
Session-Cookies schützen private Antworten nicht automatisch. So prüfen Sie Cache-Control, Vary, CDN-Regeln und Logout-Verhalten mit zwei Testkonten.
Ein Nutzer öffnet nach dem Login sein Dashboard. Kurz danach ruft ein zweiter Nutzer dieselbe URL auf – und sieht Daten des ersten Accounts.
Der erste Verdacht lautet Autorisierung. Doch die Prüfung am Origin kann korrekt sein. Der Fehler kann davor liegen: Ein gemeinsamer Cache hat eine personalisierte Antwort wiederverwendet.
Die Audit-Frage lautet deshalb: Welche Antworten dürfen zwischen Nutzern geteilt werden – und wo ist technisch garantiert, dass private Antworten davon ausgeschlossen sind?
Ein Session-Cookie ist kein Cache-Verbot
RFC 9111 stellt ausdrücklich klar, dass Set-Cookie das Caching einer ansonsten cachebaren Antwort nicht grundsätzlich verhindert. Wer Speicherung kontrollieren will, muss passende Cache-Control-Direktiven senden.
Das ist bei Cookie-Sessions besonders wichtig. Für Requests mit Authorization definiert RFC 9111 zusätzliche Regeln für Shared Caches. Ein normales Session-Cookie erzeugt keine vergleichbare automatische Schutzschicht.
Einzelne Plattformen können strengere Defaults haben. Vercel dokumentiert aktuell beispielsweise, dass Antworten mit Set-Cookie, private, no-cache oder no-store seine CDN-Cache-Kriterien nicht erfüllen. Das ist hilfreiches Plattformverhalten – aber kein Ersatz für eine explizite Policy der Anwendung.
private, no-cache und no-store sind nicht dasselbe
private verhindert die Speicherung durch Shared Caches, erlaubt aber grundsätzlich weiterhin einen privaten Browser-Cache.
no-cache bedeutet trotz des Namens nicht "nicht speichern". Die Antwort darf gespeichert werden, muss aber vor Wiederverwendung am Origin validiert werden.
no-store weist private und gemeinsame Caches an, die Antwort nicht zu speichern. OWASP empfiehlt diese Direktive für sensible Antworten, insbesondere wenn Daten nach Logout nicht aus lokalem Cache oder History wieder auftauchen sollen.
Für normale personalisierte UI kann private sinnvoll sein. Für besonders sensible Inhalte ist no-store häufig die passendere Aussage.
Drei Red Flags
1. s-maxage liegt global auf SSR-Routen. s-maxage richtet sich ausdrücklich an Shared Caches. Prüfen Sie, ob Performance-Middleware versehentlich Login-, Konto-, Checkout- oder Dashboard-Routen erfasst.
2. Die Antwort variiert nach Cookie, der Cache-Key aber nicht. RFC 9110 beschreibt Vary als Erweiterung des Cache-Keys. Vary: Cookie ist dennoch kein Allheilmittel: Consent-, Analytics- und Experiment-Cookies können die Varianten explodieren lassen. Private Seiten aus dem Shared Cache herauszunehmen ist oft robuster.
3. Die Produktions-Header unterscheiden sich vom Quellcode. Edge-Plattformen können Cache-Header ergänzen oder überschreiben. Vercel dokumentiert beispielsweise separate Cache-Control, CDN-Cache-Control und Vercel-CDN-Cache-Control Ebenen. Entscheidend ist die tatsächlich ausgelieferte Antwort.
Der Test braucht zwei Accounts
Ein einzelnes Entwicklerkonto findet Cross-User-Caching oft nicht.
- Account A öffnet eine personalisierte URL und "wärmt" den Cache.
- Response-Header,
Age, Cache-Status und sichtbare Daten werden notiert. - Account B ruft exakt dieselbe URL in einem getrennten Browser-Kontext auf.
- Beide Antworten werden verglichen.
- Der Test wird mit warmem und kaltem Cache wiederholt.
Prüfen Sie nicht nur HTML. Relevant sind auch JSON-APIs, private Downloads, PDFs, Exporte, Warenkorb und Checkout, GraphQL-GET-Requests sowie Bild- oder Dokument-Proxies.
Testen Sie außerdem Logout: Nach dem Abmelden darf ein neuer Request nicht mehr autorisiert sein. Bei sensiblen Seiten sollte auch der Back-Button keine vertraulichen Inhalte aus lokalem Cache wieder sichtbar machen.
Was Website-Pflichtencheck prüfen würde
Ein Cache- und Privacy-Audit betrachtet Anwendung, Browser, CDN und Reverse Proxy gemeinsam:
private,no-cache,no-store,max-ageunds-maxage;Varyund reale Cache-Key-Dimensionen;- Cookie- und Authorization-basierte Sessions;
- CDN- und Proxy-Overrides;
Ageund Cache-Status-Header;- Tests mit zwei isolierten Accounts;
- Logout- und Back-Button-Verhalten;
- private Downloads, Exporte und API-Antworten.
Das Ziel ist nicht "Caching aus". Das Ziel ist eine klare Grenze: Öffentliche Antworten dürfen wiederverwendet werden. Private Antworten dürfen niemals versehentlich zu gemeinsamem Inhalt werden.
Wenn niemand im Team erklären kann, ob eine eingeloggte Route im Browser, Reverse Proxy oder CDN gespeichert wird, ist das kein reines Performance-Detail. Es ist ein sinnvoller Audit-Punkt.