Hypothesis

If we use different storage backends for authenticated and anonymous sessions, we will be able to protect Sessionstore from DDoS attacks and high-volume scrapers, by not overloading it with the anonymous sessions that are created to provide CSRF prevention on authentication pages.

Context

We are seeing an increased load on Sessionstore from a combination of high-volume scraping and targeted attacks on our user account pages. Whilst we have been able to mitigate this in the short term by increasing the resources available to Sessionstore and reducing the number of writes to sessions, this is not sustainable mid- to long-term. We want to explore alternative options for session storage, including whether anonymous sessions used for CSRF protection can be stored entirely client-side.

Target outcomes

• Reduced load on Sessionstore: Reduce the volume of requests to Sessionstore from new account and login pages, with an overall decrease in storage requirements.
• Improved resilience to scraping and DDoS: Better protect our core authentication and session storage infrastructure from high-volume scraping and targeted attacks.
• Better separation of different kinds of sessions: Provide clearer and more flexible options for managing the resources used by different sessions types.

Success criteria

• All anonymous sessions migrated to new session storage management
• All authenticated sessions migrated to new session storage management
• Logged-in users better protected from session failure caused by scraping
• Reduction in growth and overall resource usage for session storage
• No regressions in CSRF or other session security protections