skip to content

What serialization and security concerns arise when externalizing sessions, and how do you handle Spring Security's SecurityContext, session fixation, and serializer choice?

level: seniorimportance: should knowfreq 38%

answer

  1. All attributes serializable; JDK default is version-fragile
  2. springSessionDefaultRedisSerializer bean → Jackson JSON
  3. SecurityJackson2Modules whitelist for SecurityContext
  4. changeSessionId() re-keys session → fixation still defended
  5. Harden cookie: HttpOnly/Secure/SameSite via CookieSerializer

basics

~20 s

Session attributes must be serializable to reach the store. Spring Security's SecurityContext is stored as a session attribute, so it must serialize too. Spring Session still supports changing the session id on login to prevent fixation. You can switch from JDK to JSON serialization.

solid answer

~40 s

Everything you put in the session is marshalled to the external store, so attributes must be serializable. By default Spring Session uses JDK serialization, which couples stored data to exact class versions and can throw on class evolution; you can register a springSessionDefaultRedisSerializer bean (e.g. Jackson-based) for JSON, which is version-tolerant and human-readable but needs typing config — notably Spring Security ships jackson modules (SecurityJackson2Modules) so the SecurityContext serializes safely. Spring Security stores its Authentication in the session, so it too must serialize. Session-fixation protection still works: on authentication Spring Security calls changeSessionId(), and Spring Session honors it by re-keying the session in the store, so the id the attacker knew is invalidated. Secure the cookie (HttpOnly, Secure, SameSite) via CookieSerializer, and remember the store now holds sensitive data.

code

java · 23 lines
java
@Configuration
@EnableRedisHttpSession
public class SessionSecurityConfig {

    // Swap JDK serialization for JSON, with Spring Security types whitelisted.
    @Bean("springSessionDefaultRedisSerializer")
    public RedisSerializer<Object> springSessionDefaultRedisSerializer() {
        ObjectMapper mapper = new ObjectMapper();
        // register the Security allow-list modules so SecurityContext round-trips
        mapper.registerModules(
            SecurityJackson2Modules.getModules(getClass().getClassLoader()));
        return new GenericJackson2JsonRedisSerializer(mapper);
    }

    @Bean
    public CookieSerializer cookieSerializer() {
        DefaultCookieSerializer s = new DefaultCookieSerializer();
        s.setUseHttpOnlyCookie(true);
        s.setUseSecureCookie(true);
        s.setSameSite("Lax");
        return s;
    }
}

go deeper

for a junior

Know that session attributes must be serializable and the login still stays secure.

for a middle

Explain that the SecurityContext is a session attribute and must serialize; know JDK vs JSON serializer exists.

for a senior

Configure springSessionDefaultRedisSerializer with SecurityJackson2Modules, reason about class-version fragility, and confirm changeSessionId re-keys the store.

for a principal

Weigh serializer trade-offs against deploy-time session loss, cross-node concurrent-session control, and treating the store as sensitive data-at-rest.

## Serialization: the central constraint Once the session lives outside the JVM, every attribute must be **serialized** on write and **deserialized** on read. This has real consequences: ### Default: JDK serialization - The default `RedisSerializer` is `JdkSerializationRedisSerializer` (and JDBC stores attributes as serialized BLOBs). Every attribute class must implement `java.io.Serializable`; a non-serializable attribute throws at write time. - **Class-version fragility:** JDK serialization ties the bytes to the class's `serialVersionUID` and field shape. Deploy a changed class and old sessions can fail to deserialize (`InvalidClassException`), effectively logging users out on deploy. This is a common production surprise. ### JSON serialization - You can replace the serializer by defining a bean **named `springSessionDefaultRedisSerializer`** — typically a `GenericJackson2JsonRedisSerializer`. Benefits: human-readable in Redis, cross-language, more tolerant of additive class changes. - **Typing caveat:** JSON needs type information to reconstruct objects, and deserializing arbitrary types is a known attack surface, so Jackson must be locked down. Spring Security provides **`SecurityJackson2Modules`** which whitelist the security types (e.g. `SecurityContextImpl`, `User`, authorities). You register those modules on the `ObjectMapper` used by the serializer so the `SecurityContext` round-trips safely. ## Spring Security integration Spring Security stores the authenticated `Authentication` inside a `SecurityContext` held as a **session attribute** (`SPRING_SECURITY_CONTEXT`). Because Spring Session's filter runs first, that attribute is written to the external store like any other. Implications: - The `SecurityContext` (and your `UserDetails`/principal) must be serializable under whatever serializer you chose. - With Redis indexing, `FindByIndexNameSessionRepository` + `SpringSessionBackedSessionRegistry` give you **concurrent-session control** (max sessions per user, force-logout) that works across nodes — something the container-only session registry can't do in a cluster. ## Session fixation **Session fixation** is an attack where the attacker fixes a known session id on the victim before login, then reuses it after the victim authenticates. The defense is to **change the session id at authentication**. Spring Security's default `changeSessionId` strategy calls `HttpServletRequest.changeSessionId()`; Spring Session implements this by **re-keying the session in the store** (new id, same attributes, old id removed). So fixation protection is preserved when externalized — but only if you keep the default strategy; disabling it (`sessionFixation().none()`) reintroduces the vulnerability. ## Cookie / transport hardening The store change doesn't remove cookie duties. Via a `CookieSerializer` / `DefaultCookieSerializer` set **`HttpOnly`** (block JS access), **`Secure`** (HTTPS-only), and an appropriate **`SameSite`** (Lax/Strict) to blunt CSRF, and scope the path/domain. If you switch to `HeaderHttpSessionIdResolver`, you shift the id to a header and take on token-handling responsibility instead. ## Data-at-rest sensitivity The external store now holds session contents — potentially principal data and CSRF tokens. Treat Redis/DB as sensitive: network-isolate it, require auth/TLS to Redis, and don't log session bodies. Externalization widens the blast radius if the store is compromised. ## When to pick which serializer - **JDK:** simplest, no config, fine if you control deploys and accept session loss on incompatible class changes. - **JSON (Jackson):** choose for readability, polyglot access, and resilience to additive changes — at the cost of typing configuration and the `SecurityJackson2Modules` setup for the SecurityContext.

  • You deployed a new version and users got logged out even though sessions were in Redis. What likely happened?
    With the default JDK serializer, a changed session-attribute class (new/removed field or changed serialVersionUID) makes old sessions fail to deserialize with InvalidClassException, so they're effectively lost. Mitigate by using JSON serialization (more tolerant of additive changes), keeping serialVersionUID stable, or minimizing what you store in the session.
  • Does session-fixation protection still work when sessions are externalized?
    Yes, provided you keep Spring Security's default changeSessionId strategy. On login Security calls changeSessionId(), and Spring Session re-keys the session in the store (new id, same attributes, old id removed), so an attacker-fixed id is invalidated. Setting sessionFixation().none() would reintroduce the risk.

saying these in an interview costs you the question

  • Assuming any object can go in the session regardless of serializability
  • Thinking externalizing sessions breaks session-fixation protection
  • Enabling Jackson JSON for sessions without SecurityJackson2Modules and then hitting deserialization errors on the SecurityContext
  • Forgetting cookie hardening because 'the session is now in Redis'
  • Not recognizing JDK serialization causes logout on incompatible class changes

context

resolving links…