CV laden
Zurück zu Business Cases

Auth

Ein Microcache, der jedes Cookie lernte

nginx cachte HTML pro auth_token. Die Trefferquote starb. Öffentliche Seiten brauchen das Cookie nicht im Key.

Anonyme Katalogseiten verfehlten den nginx-Microcache weiter. Der Cache-Key enthielt den Cookie-Header. Sanctum setzt auth_token nach dem Login auf die Session, Analytics-Cookies kommen davor. Jeder Besucher bekam einen eigenen Key. Der Zwei-Sekunden-Cache sah keinen zweiten Treffer.

Die gefährliche Version desselben Bugs ist das Gegenteil: öffentliches HTML für eine eingeloggte Antwort cachen. So leakt ein privates Fragment. Die Regel muss beide Seiten benennen.

Das Problem war Cookie als Cache-Dimension. Die Trefferquote für anonyme Käufer starb. Eingeloggtes HTML im öffentlichen Slot wäre schlimmer gewesen. auth_token muss ein Bypass-Bit sein, kein Teil des Keys.

Kein auth_token: Cache nach Host, URI, Locale. auth_token da: Bypass, nicht speichern.
Kein auth_token: Cache nach Host, URI, Locale. auth_token da: Bypass, nicht speichern.

Die Trennung

nginx sieht nur das Cookie auth_token. Fehlt es, ist der Key Scheme, Host, URI, Locale. Query-Strings ohne Einfluss auf die Seite bleiben draußen. Ist das Cookie da, sind proxy_cache_bypass und proxy_no_cache an. PHP spricht weiter mit Memcached für Fragmente. nginx speichert das personalisierte Dokument nicht.

Logout löscht das Cookie auf dem API-Host. Der nächste anonyme Hit kann den öffentlichen Slot nutzen. Login vergiftet ihn nicht, weil diese Antwort nie dorthin geschrieben wurde.

  • SameSite und httpOnly bleiben auf auth_token. JavaScript liest es nie.
  • Admin-Routen liegen gar nicht in der Microcache-Map.
  • Vary ist Locale, nicht Cookie.

Die Trefferquote der Liste kam zurück. Eingeloggtes HTML landete nie im anonymen Slot. Das Cookie blieb ein Credential, keine Cache-Dimension.

Was ich daraus mitnehme

Ein Cache-Key mit Cookie ist ein Unique-Key pro Besucher. Analytics-Cookies machen das wahr, bevor jemand einloggt.

Bypass auf einem benannten Credential ist sicherer als Vary: Cookie. Vary auf Cookie speichert trotzdem N Kopien und riskiert trotzdem einen eingeloggten Write in den öffentlichen Slot, wenn die Regel schlampig ist.

auth_token bleibt httpOnly. Edge und nginx dürfen auf Presence schauen. JavaScript liest es weiter nie.

Zurück zu Business Cases