Yes. Spring Security protects against session fixation automatically by creating a new session or changing the session ID when a user logs in. On Servlet 3.1 and newer containers the default strategy is changeSessionId, which uses the container's own protection. You normally only touch it to tighten behaviour.
What session fixation is
Session fixation is an attack where someone gets a valid session ID, persuades a victim to log in using that same ID, and then uses it to act as the victim. The Spring Security reference describes the setup as an attacker creating a session by visiting the site and sending another user a link that carries the identifier.
The defence is simple: never keep the same session ID across the privilege change from anonymous to authenticated.
The three strategies
| Strategy | What it does | Default for |
|---|---|---|
| changeSessionId | Keeps the session but changes its ID using the Servlet container | Servlet 3.1 and newer |
| newSession | Creates a clean session without copying attributes, apart from Spring Security ones | Not default |
| migrateSession | Creates a new session and copies all attributes | Servlet 3.0 and older |
The reference notes that changeSessionId is only available in Servlet 3.1 and newer, and that specifying it in older containers throws an exception. Modern Jakarta Servlet 6 setups are well past that.
Side effects to know
When protection happens, a SessionFixationProtectionEvent is published in the application context. With changeSessionId, HttpSessionIdListener implementations are notified, so the reference advises caution if you use them. Code that cached the session ID before login will see a different ID afterwards.
Steps to verify
- Open the app, note the session cookie, log in, and compare the cookie. It should differ.
- Check that your configuration has not been changed to weaken the strategy. Read any sessionManagement block in your chain.
- If you store sensitive data in the pre login session, use newSession so nothing carries over.
- Review listeners that depend on session IDs.
- Add an integration test that fails if the ID is unchanged after authentication.
- Pair this with other session basics: timeout, secure cookie flags and server side logout. See session timeouts and logout.
A worked example
An attacker opens your login page and receives a session cookie. They send a victim a link that causes the victim's browser to use that same cookie, then wait. The victim logs in. Without protection, the attacker's copy of the cookie is now an authenticated session. With the default protection, the ID changes at login, so the attacker's copy stays anonymous and useless.
That is why the check in step one is worth doing. It takes a minute and confirms a control that is easy to break by accident while changing session settings.
Safeguard scans dependencies, produces SBOMs and uses reachability analysis to show which findings your code can actually reach. You can run a free scan at gold.safeguard.sh/scan.
Quick check
Do I need to configure anything?
Usually not. The default protects on login. Configure only if you want newSession behaviour or have listeners to adjust.
Does token based authentication need this?
It applies to HTTP sessions. If you are fully stateless there is no session to fix.
Sources
Last reviewed: 19 October 2026.
