In the ever-evolving landscape of web security, some threats never quite go away—they just adapt. Session Fixation and Cross-Site Request Forgery (CSRF) have been staples on the OWASP radar for years. As we navigate 2025, developers often wonder: are these threats still relevant in modern Java applications, particularly those using Spring Boot and Spring Security?
The short answer? Yes, but with some caveats.
Let’s peel back the layers to understand where things stand today and how Java frameworks like Spring are responding. We’ll look at real-world attack patterns, some clever mitigation techniques, and why complacency—even in the age of SPA frontends and OAuth2—is still the enemy.
1. The Persistence of Session Fixation
Session fixation is an old trick. An attacker tricks a victim into using a session ID that the attacker already knows. Once the victim authenticates using that session, the attacker hijacks it and gains access to the authenticated session without needing to know credentials.
In classic web apps, where session IDs are stored in cookies, this was a serious threat. Fast forward to modern Java applications with Spring Boot and HTTPS everywhere—you’d think this wouldn’t be a problem anymore.
But here’s the twist: session fixation isn’t dead. It’s just stealthier.
For instance, a misconfigured authentication flow where the session ID isn’t regenerated upon login is still vulnerable. Imagine a system that uses Spring Security but forgets to explicitly set session management rules. An attacker sends a phishing email with a crafted session ID embedded in a link. If the app reuses that session upon login, the attacker gains access. It’s subtle, and easy to overlook.
Thankfully, Spring Security has been on top of this for a while. Since version 3.1, it has had built-in session fixation protection enabled by default. When a user logs in, Spring invalidates the old session and issues a new one. You can confirm this with:
http
.sessionManagement()
.sessionFixation().migrateSession();
Still, this protection can be accidentally disabled or misconfigured. Developers might opt for none() or newSession() without understanding the implications. That’s why security defaults matter so much—and why you should periodically audit your config, especially after a library upgrade.
2. CSRF in the Age of SPAs
Cross-Site Request Forgery, like session fixation, thrives on session-based authentication. The attack relies on tricking the user’s browser into submitting a request to a trusted site using existing session cookies. The attacker rides on the user’s session to perform malicious actions, like changing passwords or transferring funds.
For a long time, CSRF was the boogeyman of web security. But as the world moved toward stateless APIs and token-based authentication (think JWT), many developers prematurely wrote CSRF off as obsolete.
That’s a dangerous assumption.
Let’s take a modern Java backend with Spring Boot and a React frontend. If your app uses cookies for session management, you’re still a CSRF target. Even in 2025, many apps do this for simplicity, or because they’re dealing with legacy systems. The moment your cookie is HttpOnly, it can’t be read via JavaScript—but the browser will still attach it to cross-origin requests. That’s all an attacker needs.
Spring Security, to its credit, ships with CSRF protection enabled by default. But again, problems arise when developers disable it, thinking that SPAs or REST APIs are immune. You’ve probably seen this:
http.csrf().disable();
It’s a red flag. While disabling CSRF might be valid for true stateless APIs that only accept Authorization headers, it’s often misused.
Token-based CSRF Mitigation: A Better Approach
If your app is stateful or uses cookies, keep CSRF protection enabled. Spring’s CSRF token mechanism can be integrated into SPAs by exposing the token via a custom endpoint and attaching it to requests manually. Something like:
@GetMapping("/csrf-token")
public CsrfToken csrf(CsrfToken token) {
return token;
}
On the frontend, your JavaScript client can fetch and attach this token as an HTTP header, say X-CSRF-TOKEN, on each modifying request.
In recent discussions from Hacker News and Reddit’s r/java, developers argue that modern frontend frameworks have made CSRF harder to exploit—but not impossible. Many real-world attacks are found not in the logic, but in the gaps—when switching auth methods, during login flows, or on edge-case routes that developers forget to harden.
3. OAuth2, JWTs, and the Myth of Immunity
Some developers, especially those integrating OAuth2 in Spring Security, assume CSRF is no longer a concern. That’s half true. When using Bearer tokens in the Authorization header and storing them in localStorage (a common practice), CSRF attacks don’t work—because the browser doesn’t automatically attach tokens like it does with cookies.
However, this introduces another beast: XSS. If an attacker injects JavaScript into your page, they can read your localStorage tokens and exfiltrate them. So it’s a trade-off—CSRF is off the table, but now XSS becomes more critical to defend against.
To strike a balance, some teams use Double Submit Cookies, where the CSRF token is stored in both a cookie and a request header. Others go fully stateless and wrap all logic in short-lived access tokens and refresh flows.
4. Are We Safe Yet?
The reality in 2025 is nuanced. The tools have improved. Spring Security is battle-tested. Defaults are safer. But no framework can protect you from poor assumptions.
Attackers now look for hybrid flaws. They’ll combine session fixation with subdomain takeover. Or pair a CSRF attack with a race condition on an endpoint with poor authorization checks. It’s no longer about just enabling or disabling a setting—it’s about understanding the full authentication and session lifecycle.
5. Final Thoughts
So, are session fixation and CSRF still threats in 2025?
Absolutely—but in quieter, sneakier forms. The fundamentals haven’t changed, but the delivery has evolved. Modern Java apps built with Spring Boot are far safer than they were a decade ago—but not bulletproof.
Here’s the bottom line: Trust Spring Security’s defaults. Don’t disable protections unless you really know why. And treat authentication as a flow, not just a login form. Your architecture—stateful vs. stateless, cookie-based vs. token-based—dictates your threat model.
As one commenter on Stack Overflow eloquently put it: “Security is not about avoiding the past. It’s about remembering it better than your attacker does.”
6. References
- OWASP Session Fixation
- OWASP CSRF
- Spring Security Docs – Session Management
- Spring Security Docs – CSRF Protection
- Stack Overflow discussion on session fixation
- Reddit r/java – Modern authentication best practices
- Hacker News – CSRF misconceptions in modern web apps
