Sessions & Cookies

The Problem: HTTP Has No Memory — and the Two Ways to Add It

HTTP is stateless: every request is independent. The server receives a request, processes it, sends a response, and immediately forgets the connection existed. This is a deliberate design decision that makes HTTP scalable and simple — but it means that without additional mechanisms, a user would have to authenticate on every single request.

// Without any state mechanism — server forgets instantly
Request 1:  POST /login  {email: "ada@example.com", password: "..."}
Response 1: 200 OK  "Welcome Ada"

Request 2:  GET /dashboard
Response 2: 401 Unauthorized  "Who are you?"   // server has no memory

Two mechanisms exist to solve this, and they solve it differently:

// With session-based authentication — the server remembers via a shared key
Request 1:  POST /login  {email: "ada@example.com", password: "..."}
Response 1: 200 OK
            Set-Cookie: JSESSIONID=f3a9b12c...  // server creates session, sends back the ID

Request 2:  GET /dashboard
            Cookie: JSESSIONID=f3a9b12c...       // browser sends it automatically
Response 2: 200 OK  {user: "Ada Lovelace", ...}   // server looks up session by ID

Cookies: Anatomy and Security Flags

A cookie is a name/value pair set by the server via Set-Cookie and sent by the browser on every subsequent request to the matching domain and path. The attributes that follow the value control its security surface — getting them wrong is where most real cookie vulnerabilities come from.

Set-Cookie: auth_token=eyJhbGciOi...;
            Path=/;
            Max-Age=3600;
            Secure;
            HttpOnly;
            SameSite=Strict

Setting and Reading Cookies in Spring

// Setting — always prefer ResponseCookie over the legacy Cookie API
// The legacy Cookie class predates SameSite support and can't set it.
@PostMapping("/login")
public ResponseEntity<Void> login(@Valid @RequestBody LoginRequest request) {
    String sessionId = authService.authenticate(request);   // throws on bad credentials

    ResponseCookie cookie = ResponseCookie.from("session_id", sessionId)
        .httpOnly(true)
        .secure(true)
        .sameSite("Lax")
        .path("/")
        .maxAge(Duration.ofHours(8))
        .build();

    return ResponseEntity.ok()
        .header(HttpHeaders.SET_COOKIE, cookie.toString())
        .build();
}

// Reading — @CookieValue is cleaner than scanning request.getCookies()
@GetMapping("/profile")
public UserResponse getProfile(
        @CookieValue(name = "session_id", required = false) String sessionId) {
    if (sessionId == null) {
        throw new UnauthorizedException("No session");
    }
    return sessionService.getUser(sessionId);
}

// Deleting — set Max-Age to 0 with the same path as when it was created
@PostMapping("/logout")
public ResponseEntity<Void> logout() {
    ResponseCookie expired = ResponseCookie.from("session_id", "")
        .httpOnly(true)
        .secure(true)
        .sameSite("Lax")
        .path("/")
        .maxAge(0)   // instructs browser to delete immediately
        .build();

    return ResponseEntity.noContent()
        .header(HttpHeaders.SET_COOKIE, expired.toString())
        .build();
}

Server-Side Sessions: HttpSession and the Scaling Problem

A session stores data on the server keyed by a cryptographically random session ID. The browser holds only that ID — the actual data (user identity, cart contents, permissions) never leaves the server. This is the key security property: even if someone intercepts or steals the session ID cookie, they get a meaningless opaque string unless they can also reach the server's session store.

// Spring MVC — HttpSession is injected directly
@PostMapping("/login")
public ResponseEntity<Void> login(@Valid @RequestBody LoginRequest request,
                                    HttpServletRequest httpRequest) {
    User user = authService.authenticate(request);   // throws UnauthorizedException on failure

    // Session fixation prevention: invalidate any pre-login session,
    // then create a fresh one with a new ID. Without this, an attacker
    // who knows a victim's pre-login session ID can hijack it post-login.
    HttpSession old = httpRequest.getSession(false);
    if (old != null) old.invalidate();

    HttpSession session = httpRequest.getSession(true);
    session.setAttribute("userId", user.getId());        // store the ID, not the whole entity
    session.setAttribute("roles", user.getRoles());
    session.setMaxInactiveInterval(30 * 60);              // 30 min inactivity timeout

    return ResponseEntity.ok().build();
}

@GetMapping("/dashboard")
public DashboardResponse getDashboard(HttpSession session) {
    Long userId = (Long) session.getAttribute("userId");
    if (userId == null) {
        throw new UnauthorizedException("No active session");
    }
    return dashboardService.forUser(userId);
}

@PostMapping("/logout")
@ResponseStatus(HttpStatus.NO_CONTENT)
public void logout(HttpSession session) {
    session.invalidate();   // destroys the server-side data; the cookie becomes orphaned
}

The Horizontal Scaling Problem — and Its Fix

// DEFAULT: sessions live in each instance's JVM heap
┌─────────────────┐     ┌─────────────────┐
│   Instance A    │     │   Instance B    │
│  session abc123 │     │  (no sessions)  │
└────────┬────────┘     └────────┬────────┘
         │ Load Balancer                   │
         └─────────────────────────────────┘

// Request 1 → Instance A: login succeeds, session abc123 created
// Request 2 → Instance B: no session abc123 → user appears logged out
// This is why sticky sessions (pinning a user to one instance) exist —
// but they're a workaround, not a solution. They make deployments and
// failovers fragile.

// FIX: Spring Session externalises session storage transparently
// The application code doesn't change — only the dependency and one property line.

<!-- pom.xml -->
<dependency>
    <groupId>org.springframework.session</groupId>
    <artifactId>spring-session-data-redis</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

# application.properties
spring.session.store-type=redis
spring.session.timeout=30m
spring.data.redis.host=${REDIS_HOST}
spring.data.redis.port=6379

// Now all instances share the same session store.
// Any request to any instance finds the same session.

┌─────────────────┐     ┌─────────────────┐
│   Instance A    │     │   Instance B    │
└────────┬────────┘     └────────┬────────┘
         │                       │
         └───────────┬───────────┘
                     │
              ┌──────┴──────┐
              │    Redis    │
              │  session    │
              │  abc123     │
              └─────────────┘

Spring Boot Session Properties

# application.properties — one place to configure all session cookie behaviour
server.servlet.session.timeout=30m
server.servlet.session.cookie.name=SESSION
server.servlet.session.cookie.http-only=true
server.servlet.session.cookie.secure=true
server.servlet.session.cookie.same-site=lax

The Three Security Attacks You Must Defend Against

1. Session Fixation

An attacker who can set a victim's session ID before they log in (via a URL parameter, a known network, or a shared computer) can hijack the session the moment the victim authenticates. The fix is always the same: invalidate the pre-authentication session and create a new one with a fresh ID on successful login.

// Spring Security handles this automatically — explicit config shown for clarity
@Configuration
public class SecurityConfig {
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.sessionManagement(session -> session
            .sessionFixation().newSession()   // new ID, preserves attributes (the safe default)
            // .sessionFixation().migrateSession() — same, older name, equivalent
            // .sessionFixation().changeSessionId() — cheapest: changes ID only, no copy needed
        );
        return http.build();
    }
}

2. XSS (Cross-Site Scripting) and Cookie Theft

If an attacker can inject JavaScript that executes in your page, and your session cookie is readable via document.cookie, the attack is trivial: one line of JavaScript exfiltrates the session ID to an attacker-controlled server. HttpOnly removes the cookie from JavaScript's reach entirely — the script cannot read a value that doesn't appear in document.cookie. This is not optional for any authentication cookie.

3. CSRF (Cross-Site Request Forgery)

A malicious page on another domain loads an image or submits a form targeting your API. The victim's browser — being helpful — includes the session cookie automatically. Without a defense, the server has no way to tell whether the request was initiated by your application or by a malicious third-party page. Two defenses exist, and in 2026 SameSite=Lax alone handles the common case without additional complexity.

// Defense 1: SameSite=Lax (the modern default, sufficient for most apps)
// Lax blocks embedded cross-site requests (forms, XHR, fetch) but allows
// top-level GET navigations (clicking a link into your site).
// It does NOT block a cross-site POST form — that's why Strict exists.

// Defense 2: CSRF token — the classic defense, still needed for SameSite=None
@Configuration
public class SecurityConfig {
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            // Spring Security enables CSRF protection by default for stateful apps.
            // It generates a token that must be sent in a header or form field —
            // a cross-site page cannot read this token, so it can't forge the request.
            .csrf(Customizer.withDefaults())

            // For pure REST APIs that use stateless JWT, not sessions, CSRF is
            // typically disabled — there's no cookie for a cross-site page to exploit:
            // .csrf(csrf -> csrf.disable())
            ;
        return http.build();
    }
}

Sessions vs JWT — the Real Trade-offs

Sessions and JWTs (JSON Web Tokens) are not interchangeable. They solve the same problem — "how does the server know who this request is from?" — with fundamentally different properties, and choosing the wrong one for a given context creates real operational problems.

// Session-based flow
Browser ──── Cookie: JSESSIONID=abc123 ────▶ Server
                                              └─▶ Redis: look up "abc123"
                                              └─▶ Returns: {userId: 42, roles: ["ADMIN"]}
// One network hop to Redis per request under the session path.
// Revocation: delete the key from Redis → session is dead immediately.

// JWT-based flow
Client ──── Authorization: Bearer eyJhbGci... ────▶ Server
                                                    └─▶ Verifies cryptographic signature (local)
                                                    └─▶ Reads: {userId: 42, roles: ["ADMIN"], exp: ...}
// Zero network hops for verification — just CPU (signature check).
// Revocation: the token is valid until its exp claim, period.
// If you need to revoke before expiry, you need a blocklist — which means
// a network hop to check it, collapsing the "no database lookup" advantage.

The "Remember Me" Pattern

Short session timeouts (30 minutes) are correct for security but frustrating for users on their personal devices. The "remember me" pattern provides a long-lived persistent token separate from the session — so the session can expire while the user stays logged in on their own device without permanently weakening security.

@PostMapping("/login")
public ResponseEntity<Void> login(
        @Valid @RequestBody LoginRequest request,
        @RequestParam(defaultValue = "false") boolean rememberMe,
        HttpServletRequest httpRequest,
        HttpServletResponse httpResponse) {

    User user = authService.authenticate(request);

    HttpSession old = httpRequest.getSession(false);
    if (old != null) old.invalidate();   // session fixation prevention
    httpRequest.getSession(true).setAttribute("userId", user.getId());

    if (rememberMe) {
        String token = rememberMeService.createToken(user);   // stored hashed in DB
        ResponseCookie persistent = ResponseCookie.from("remember_me", token)
            .httpOnly(true)
            .secure(true)
            .sameSite("Lax")
            .path("/")
            .maxAge(Duration.ofDays(30))
            .build();
        httpResponse.addHeader(HttpHeaders.SET_COOKIE, persistent.toString());
    }

    return ResponseEntity.ok().build();
}

Best Practices and Common Pitfalls

Interview Questions