In many languages and web frameworks, the assumption is that the application server will do this for you. For example, by issuing a new env variable with each r

In many languages and web frameworks, the assumption is that the application server will do this for you. For example, by issuing a new env variable with each request such that requests can't easily share memory with other requests, though as noted that might not stop background threads from retaining such memory. In other cases, you might assume containers would be enough separation, or maybe different databases (sharding, for example). One approach I've considered but not yet implemented is to take end-user JWT cookies and use them to authenticate to a database such that a user can only ever see the rows they should be allowed access to, and all other SQL queries would fail. But no matter how you implement a security control, it's possible to make mistakes and allow others to see data you didn't intend to share with them. Even Rust, famous for its explicit memory ownership model, could still have similar bugs, they just might be a bit more obvious to spot in some session connection pool implemented incorrectly, for example, or maybe exposed via a compiler optimization gone wrong. Code review will still likely be one of the primary defenses of this kind of bug, though hopefully better tooling and language support to detect race conditions or shared ownership warnings will help over time?