Sticky sessions are not a vulnerability by themselves, but they tie user state to one process, which makes restarts lose sessions and hides state where you cannot control it. Twelve-factor says processes should be stateless and share-nothing, with session data in a datastore that expires entries.
What stateless means
The methodology states that any data that must persist goes into a stateful backing service, typically a database. Memory and the local filesystem may serve as a brief, single-transaction cache. The app never assumes that something cached in memory or on disk will be there for the next request or job, because a later request may land on a different process, and a restart usually wipes local state anyway.
On sticky sessions it is blunt: they are a violation of twelve-factor and should never be used or relied upon. Session state is described as a good candidate for a datastore with time-based expiry.
The security upside of a shared session store
Moving sessions into one store gives you levers that scattered process memory does not.
- Central expiry. You can set a time to live and enforce it in one place.
- Central revocation. To log a user out everywhere, or to kill sessions after a suspected account takeover, you delete entries in one store.
- Restart safe. Deploying a fix does not randomly sign users out or, worse, leave an old process with stale permissions in memory.
- Fewer hidden copies. Session data is not sitting in the heap of a dozen processes.
The new risk you take on
A session store becomes a high value target. It holds the keys to every logged in user.
- Require authentication and encryption in transit to the store.
- Do not expose it beyond the services that need it.
- Store a random session identifier in the cookie and keep user data server side, or sign and encrypt anything that stays client side.
- Set cookie attributes such as Secure and HttpOnly where your framework allows.
- Do not log session identifiers. The OWASP logging guidance lists session identification values among items to remove, mask or hash.
Local files and memory caches
The same rule covers uploads and temporary files. If a process writes a user's file to local disk and a later request expects it there, the app breaks on the next restart and the file may linger after it should be gone. Treat local disk as scratch space. Anything sensitive that touches it should be cleaned up, and the container filesystem is best kept read only where the app allows. A shared store with a clear retention rule is easier to reason about and to delete from.
When stickiness is still seen
Some load balancers offer stickiness for performance, for example to keep a user near a warm cache. That is a performance choice. If correctness or security depends on it, you have built state into the process. Test by killing a process during a session: the user should carry on without noticing.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the web app scan and look at how session related findings are reported and prioritized.
Quick check
Is it unsafe to keep session data in process memory?
It is fragile more than unsafe: sessions vanish on restart and you cannot revoke them centrally. A shared store with expiry gives better control.
Where should a stateless app keep uploaded files?
In a backing service such as object storage or a database, not on the local disk. Local disk is only a short lived scratch area.
How do I test that a service is really stateless?
Run two instances behind the load balancer, stop one in the middle of a user session, and confirm the user's next request still works.
Where Safeguard fits
Safeguard's dependency scanning and SBOM generation show which session, cache and framework libraries you ship and flag known vulnerable versions, and reachability analysis helps you decide which findings to fix first. A free scan is a quick starting point.
Sources
Last reviewed: 19 October 2026.
