Understanding Java Session and Cookie: A Hands‑On Spring Boot Demo

Session and Cookie Basics

HTTP is a stateless protocol, so web applications use Session (server‑side) and Cookie (client‑side) to remember request state. In a traditional monolithic setup Tomcat stores the session in memory; for distributed scenarios developers often back sessions with Redis, JDBC, or MongoDB, which Spring can configure automatically. The session identifier is communicated to the client via a cookie named JSESSIONID. While most cookies are rarely needed, the JSESSIONID cookie is essential because it links the client request to the server‑side session.

Code Example

A tiny Spring Boot controller demonstrates how a session attribute can be set and read. The endpoint http://localhost:8080/test/cookie?browser=xxx stores the browser parameter in the session if the session does not already contain it, otherwise it prints the stored value. All request cookies are also printed.

@Controller
@RequestMapping("/test/cookie")
public class CookieController {
    public String cookie(@RequestParam("browser") String browser,
                       HttpServletRequest request,
                       HttpSession session) {
        Object sessionBrowser = session.getAttribute("browser");
        if (sessionBrowser == null) {
            System.out.println("Session not found, setting browser=" + browser);
            session.setAttribute("browser", browser);
        } else {
            System.out.println("Session exists, browser=" + sessionBrowser.toString());
        }
        Cookie[] cookies = request.getCookies();
        if (cookies != null && cookies.length > 0) {
            for (Cookie cookie : cookies) {
                System.out.println(cookie.getName() + " : " + cookie.getValue());
            }
        }
        return "index";
    }
}

Testing with Chrome

First request (e.g., browser=chrome) yields no existing session, so the controller stores browser=chrome and prints:

SessionInfo: session not found, setting browser=chrome

Subsequent requests return the stored value and the automatically generated JSESSIONID cookie, e.g.:

SessionInfo: session exists, browser=chrome
CookieInfo: JSESSIONID: 4CD1D96E04FC390EA6C60E8C40A636AF

Testing with 360 Browser

Repeating the same steps with the 360 browser (using browser=360) creates a separate session and a different JSESSIONID value, confirming that sessions are isolated per browser instance.

SessionInfo: session not found, setting browser=360
CookieInfo: JSESSIONID: 320C21A645A160C4843D076204DA2F40

Security Issue

Because the server relies solely on the JSESSIONID cookie to locate the session, an attacker who copies a valid cookie from one browser to another can impersonate the original user. The article demonstrates this by editing Chrome’s JSESSIONID to the value obtained from the 360 browser, after which the server returns the session data associated with the 360 browser ( browser=360), proving the vulnerability.

These observations underline the importance of protecting session cookies (e.g., using HttpOnly, Secure flags, and short expiration) and avoiding reliance on client‑side storage for sensitive authentication data.