Session Management

What is Session Management — and Why Does it Exist?

HTTP is stateless — every request arrives with no memory of the previous one. A session is the mechanism that lets a server recognize "this request belongs to the same authenticated user as the last one," so a customer doesn't have to re-enter credentials on every page of a checkout flow. The server generates a session identifier, hands it to the client as a cookie, and keeps the actual authenticated state — who this is, what's in their cart, what roles they have — on the server side, keyed by that identifier.

This page is about the security engineering around that mechanism, not the cookie attributes themselves — Secure, HttpOnly, and SameSite are covered in depth on Sessions & Cookies. What belongs here is what goes wrong when session identifiers are predictable, when they aren't regenerated at the moment of login, when logout doesn't actually destroy server-side state, and when a stateful session model needs to survive more than one server instance.

// BEFORE — a hand-rolled, predictable session identifier
String sessionId = customer.getId() + "-" + System.currentTimeMillis();
// An attacker who knows (or can enumerate) a customer ID and a rough login
// time can construct valid session identifiers directly — no theft required,
// just guessing within a narrow, predictable search space.

// AFTER — Spring Security's container-managed session, high-entropy by default
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    return http
        .sessionManagement(session -> session
            .sessionFixation(fixation -> fixation.changeSessionId())   // new ID issued on login
        )
        .build();
    // The session ID itself is a cryptographically random token generated by the
    // servlet container (SecureRandom-backed) — nothing about it is derivable
    // from the user's identity, login time, or any other guessable value.
}

Session Identifier Entropy — Why It Must Be Unguessable, Not Just Unique

A session ID has exactly one job from a security standpoint: an attacker who doesn't already have it must not be able to compute or predict it. A UUID is unique, but not every UUID generation strategy is cryptographically random — version 1 UUIDs embed a timestamp and MAC address and are absolutely not appropriate as a session identifier. Servlet containers (Tomcat, and by extension Spring Boot's embedded server) generate session IDs from SecureRandom with enough bits of entropy that brute-forcing one is computationally infeasible — this is not something application code needs to implement, only something it must not accidentally override with something weaker.

Session Fixation — The Attack That Regeneration Defeats

Session fixation works by having the attacker set (or simply know) a session ID before the victim authenticates. If the application keeps using that same session ID after login — merely upgrading it from anonymous to authenticated in the store — the attacker, who already holds that ID, is now authenticated as the victim too.

/*
 * The attack, step by step:
 *
 * 1. Attacker visits the login page, receives session ID "ABC123" (unauthenticated).
 * 2. Attacker tricks the victim into using a link that carries that same ID
 *    (e.g. https://shop.example.com/login;jsessionid=ABC123 on a container
 *    that accepts session IDs via URL rewriting).
 * 3. Victim logs in. If the application reuses "ABC123" as-is, it is now an
 *    AUTHENTICATED session under that identifier.
 * 4. Attacker, who already has "ABC123", is now logged in as the victim —
 *    no credential theft occurred at all, only identifier reuse.
 */

// THE FIX: issue a brand-new session ID at the moment of authentication,
// regardless of whether one already existed
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    return http
        .sessionManagement(session -> session
            .sessionFixation(fixation -> fixation.changeSessionId())
            // changeSessionId() is Spring Security's DEFAULT since 4.x — this is shown
            // explicitly for clarity, not because it needs to be added by hand.
            // migrateSession() and newSession() are the older, JEE-container-level
            // alternatives; changeSessionId() is preferred because it preserves
            // session attributes instead of discarding them.
        )
        .build();
}

Invalidation — Why Deleting the Cookie is Not the Same as Logging Out

Clearing a cookie on the client only stops that browser from sending the identifier again — it does nothing to the session state still sitting in the server's store. If an attacker captured the session ID before the legitimate user "logged out" client-side, that captured ID remains valid and authenticated until the server-side entry is explicitly destroyed or expires on its own.

// Correct logout: invalidate server-side state, THEN clear the client cookie
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    return http
        .logout(logout -> logout
            .logoutUrl("/api/auth/logout")
            .invalidateHttpSession(true)     // destroys the server-side session entry
            .clearAuthentication(true)      // clears the SecurityContext for this request
            .deleteCookies("JSESSIONID")   // tells the browser to stop sending it too
        )
        .build();
}

// Password change is a security-sensitive event that should kill EVERY OTHER
// session for that user, not just the current one — otherwise a session an
// attacker already hijacked survives the victim's own password change.
@Service
public class PasswordChangeService {

    private final SessionRegistry sessionRegistry;
    private final CustomerRepository customerRepository;
    private final PasswordEncoder passwordEncoder;

    public PasswordChangeService(SessionRegistry sessionRegistry,
                                CustomerRepository customerRepository,
                                PasswordEncoder passwordEncoder) {
        this.sessionRegistry = sessionRegistry;
        this.customerRepository = customerRepository;
        this.passwordEncoder = passwordEncoder;
    }

    public void changePassword(String username, String newRawPassword) {
        Customer customer = customerRepository.findByUsername(username).orElseThrow();
        customer.setPasswordHash(passwordEncoder.encode(newRawPassword));
        customerRepository.save(customer);

        // Expire every registered session for this principal — including any
        // session an attacker may currently hold without the user's knowledge
        sessionRegistry.getAllSessions(username, false)
            .forEach(SessionInformation::expireNow);
    }
}

Concurrent Session Control and Timeout Policy

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    return http
        .sessionManagement(session -> session
            .sessionFixation(fixation -> fixation.changeSessionId())
            .maximumSessions(1)                      // one active session per account at a time
                .maxSessionsPreventsLogin(false)  // false = new login WINS, kicks out the old session
                .expiredUrl("/login?expired")      // where the kicked-out session gets redirected
        )
        .build();
}

Scaling Sessions — Why In-Memory Storage Breaks Beyond One Instance

The default servlet session store lives in the JVM's heap. That's fine for a single instance, but it breaks the moment you run more than one: a load balancer without sticky sessions can route request 2 of the same user to an instance that has never seen their session ID, and the user is unexpectedly logged out. Sticky sessions "solve" this by pinning a user to one instance — at the cost of uneven load distribution and total session loss if that specific instance restarts or is scaled down.

// Spring Session backed by Redis: sessions live in a shared, external store
// that every application instance reads from and writes to identically —
// no stickiness required, and a rolling deploy doesn't log anyone out.

// build.gradle / pom.xml: spring-boot-starter-data-redis + spring-session-data-redis

# application.yml
spring:
  session:
    store-type: redis
    redis:
      namespace: shop:sessions
  data:
    redis:
      host: ${REDIS_HOST}
      port: 6379

@Configuration
@EnableRedisHttpSession(maxInactiveIntervalInSeconds = 1800)
public class SessionConfig {}
// From this point, HttpSession is transparently backed by Redis — application
// code that calls request.getSession() doesn't change at all. Instance count
// can now scale horizontally, and any instance can serve any request for any
// authenticated user.

Best Practices and Common Pitfalls

Interview Questions