Editing Shared Resources: "Client Owns The Resource"
What if session data was never in a backend system like Redis, but encrypted and sent to the browser instead? It means each browser request would carry around its own specific version of the data. It’s a fairly common approach with some frameworks (Rails, .Net, etc) called “Client Side Sessions”. There’s a number of pros and cons to this.
Pros
No need to replicate sessions across a data center, because it’s in the browser.
It appears as if each user “holds” their own data.
Cons
Extra kilobytes on every request (ok, sometimes it’s just bytes, but not usually).
Increases the overall security risk due to the reality that “getting encryption security right is just really, really hard” or “the developer accidentally put too much sensitive data in the session“.
There’s a lot of conflicting advice on the right way to implement this in a secure way, you really need to do your homework to prevent an XSS attack. Some libraries have shipped with “broken by default” code.
Storage limitations of 4k when using secure cookies. One can argue all session data should be under 4k, but I’ve seen real production systems passing around 50mb strings because “the developer accidentally put too much data in the session”. It’s more common than you’d expect.
The data ownership model is inverted here, and unless there’s some browser-side code to handle it (which would expose the session to XSS attacks) it will be back to the “YOLO” locking style (article from earlier), just on the browser instead of the backend.
