Sessions, browser credentials and CSRF
Prerequisites: 01-ecosystem
How do sessions survive replica changes?
Goal & mental model verified
Spring Session externalizes session handling through shared implementations. CSRF is about a browser automatically attaching credentials to a forged request; it is not solved by calling the API “REST.”
[S34] [S35]Worked example · design exercise synthesis
A browser broker portal uses a session cookie and CSRF token on state-changing requests. Two app replicas can access shared session state instead of relying solely on one process’s memory.
[S34] [S35]Engineering decision synthesis
Choose session or bearer-token flows from client and threat requirements. Shared sessions improve replica mobility but introduce storage availability, expiration and serialization concerns.
[S34] [S35]Pitfall & diagnosis synthesis
Stateless does not automatically mean CSRF-safe if browser credentials are still sent automatically. CORS policy is not a replacement for CSRF protection.
[S34] [S35]Improve & validate synthesis
Exercise expiration, logout, replica changes and state-changing cross-origin requests. Confirm credential behavior and token checks for the actual browser flow.
[S34] [S35]Check yourself: Why can a cookie API need CSRF protection?
Because a browser can automatically attach the cookie to a forged request.