Cookies & Sessions

We’ve ALL had the experience of browsing through a blog article, then the website asking us for our cookies. I remember 10 year old me was terrified that all my personal information and IP address were going to be stolen(never was the case btw) when I clicked accept on one of the pop-up cookie notices.

The reason websites ask for your cookies is so they can “remember you.” Beyond just that, you might have noticed that online stores keep your items in the shopping cart as you browse different pages. Similarly, you stay logged into Instagram without having to re-enter your password every couple of minutes.

The magic behind this is due to two key concepts of data storing: cookies and sessions. They’re often mentioned together but they serve distinct purposes.

What are cookies?

Cookies are small pieces of data that is used to maintain and manage the state between the client(web browser) and the server.

Whenever the client sends a request to the server, the server sends a small piece of data, a cookie, to the client along with the response to that request. This data is then stored locally in the client’s device. Note that this mechanism overcomes HTTP’s stateless property.

Key characteristics:

Storage location: client-side
Purpose(mainly used for):
- Session management– maintaining login status, shopping cart contents, game scores
- Personalization– remembering user preferences such as language settings, theme choices, etc
- Tracking– analyzing user behavior, often for analytics or targeted advertising purposes
Size limit: generally 4KB, which is very small
Expiration: editable. Ranges could be from seconds to an eternity
Data format: text
Security: less secure than sessions, due to the data format being text

Also, here is a VERY SIMPLE code strip that shows an example how cookies are used(its from one of my previous projects):

Cookie loginCookie = WebUtils.getCookie(request, "login_id");
        if (loginCookie == null) {
            return "redirect:/login";
        }

Here, the cookie sent by the client is compared to the one stored on the server. If they don’t match, the user is redirected to the login page.

What are Sessions?

Sessions are server-sided mechanisms for managing user-specific data and state. More specifically, what sessions do is that they link a unique session ID(stored in a cookie) to data held in a session store.

When a user first interacts with a web application, the server generates a unique, usually random, session ID for that specific user’s current visit. This ID act as a key. To ensure the client(web browser) can “identify” itself on reoccurring requests, this session ID is sent to the client, stored as a temporary cookie(also called a session cookie). This cookie contains only the session ID, not the actual sensitive data.

For every following request the client makes to the web application, it automatically includes this session cookie containing the session ID. The server then receives this ID and uses it to look up all the relevant information it has been collecting about your visit in its session store. This session store is a dedicated storage area of the server (could be in the server’s memory, a database, or a specialized caching system) where the actual user specific data is kept.

tl;dr: just look at this diagram.

Key characteristics:

Storage location: server-side
Purpose(mainly used for):
- Authentication– securely managing user login states, ensuring sensitive user data(passwords or payment info) is not stored on the client.
- Temporary data storage– holding user-specific data that is relevant only for the current interaction
Size limit: varies by server resources(128MB in php)
Expiration: as long as the browser is open
Data format: binary(0s and 1s)
Security: secure to an extent, data can be only decrypted at the server

FrogCode