Cookie and Session (I): The basic concept

7 min readNov 29, 2021

Why do we need cookie?

Cookie solves the problem of stateless HTTP request.

Every HTTP request is a new request. When you visit a website. The server cannot recognise who you are even though you may have visited it before. It is because every request from the client (also called browser or user agent) to the server is treated as a new request.

That is why we describe HTTP request as‘stateless’.

This feature causes difficulty for developing web applications, such as e-commerce website that keeps track of customers’ shopping carts. Yet, due to the stateless feature, the customer will lose their shopping cart data after closing the browser.

Therefore, the RFC about cookie is named HTTP State Management Mechanism, aiming to solve the problem of stateless HTTP request. Moreover, the RFC introduced the term ‘session’ and two new headers in HTTP request and response, Cookie and Set-cookie.

RFC 2109 — HTTP State Management Mechanism — 1997 Feb

This document describes a way to create stateful sessions with HTTP requests and responses. Currently, HTTP servers respond to each client request without relating that request to previous or subsequent requests; the technique allows clients and servers that wish to exchange state information to place HTTP requests and responses within a larger context, which we term a “session”.

In other words, ‘session’ means a context, which involves an interaction between the server and client. It can maintain and exchange a user’s state information.

Key attributes of session mentioned in RFC 2109:

Each session has a beginning and an end.Each session is relatively short-lived.Either the user agent or the origin server may terminate a session.The session is implicit in the exchange of state information.

In short, session allows server and client exchange state information within a particular period of time. It can also be terminated by the client or server.

How does cookie work?

Cookie can be set by:

Server with using Set-cookie header.
Using JavaScript document.cookie.

If a cookie is set with HttpOnly, it cannot be edited by scripting languages.

The whole picture of how cookie and session are used

The picture above describes implementing authentication by using cookie and session. It is called session-based authentication.

The first time to login

Send POST request to the server, with your username and password
Server receives request. Create session ID ‘abc123’ as your unique identifier
Store the sessionId in database
Return response with Set-cookie: sessionId=abc123, for setting the session ID in your browser

The next time you login

Browser sends a POST request to the server, with session ID stored in your browser’s cookie
Server searches for your information based on your session ID
Server checks if the session ID is valid or not
Server returns your information through a response

The main difference is that the server will create a session ID if you login for the first time.

The purpose of session ID will be discussed later in this article.

Details

After understanding the basic concepts, we can take a look at a more detailed steps of how server and client exchange session (state information of the user), including:

How does server set cookie? (Server → Client)
How does client send cookie to server? (Client → Server)

The example below takes reference from Wikipedia. Compared to the previous example, it demonstrates setting more than one cookie in the response.

How does server sets cookie? (Server → client)

Client sends a HTTP request to the homepage of www.example.org

GET/index.htmlHTTP/1.1
Host: www.example.org
...

2. Server responses with two Set-cookie headers

HTTP/1.0 200OKContent-type: text/html
Set-Cookie: theme=light
Set-Cookie: sessionID=abc123; Expires=Wed, 09 Jun 2021 10:18:14 GMT
...

The server uses Set-Cookie HTTP-header in the response for setting cookie.

The two cookies are different. theme=light and sessionToken=abc123 are called session cookie and persistent cookie respectively. The only difference here is whether the Expires attribute is set.

Session cookie

No Expires attribute is set. When the browser is closed, the cookie will be deleted.

Persistent cookie

A cookie that will be deleted by the browser based on its Expires attribute. When the browser is closed, it will not be deleted.

Server creates session ID for each user

In the above response, server creates a session ID abc123 and attaches it in the response. Session ID works as an 'unique identifier' for identitying each user. The server will store the user's information with his unique session ID in database.

3. Client visits spec.html page on www.example.org website

GET/spec.htmlHTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionID=abc123
…

When the user visits another page spec.html in the website, server can retrieve his information based on the session ID stored in the user’s cookie.

Now we know how server sets cookies in response. The following explanation is about how client sends cookie through a HTTP request.

How does client sends cookie to server? (Client → Server)

Steps

Steps of sending a request with Cookie request header:

Client sends a HTTP request to the server
Browser checks with all stored cookies’ attributes, such as Domain, Path, Expires and HttpOnly attributes. For example, domain and path attribute show what website does the cookie belong to. Be aware that the browser does not include these attributes in the request, they are only used by browser for deciding whether the cookie will be included in the request
Browser finds out the cookie(s) that fulfil the requirement, such as having an unexpired, correct domain, path and HttpOnly setting
Browser sends the correct cookie(s) in the Cookie header, only with their names and values

Cookie header is sent with the following key-value pair format, with semicolon and space ; as the separator:

Cookie: name=value; name2=value2; name3=value3

Be aware that you cannot set cookie that is different from your domain.

MDN mentions:

A cookie for a domain that does not include the server that set it should be rejected by the user agent

User agent means client or browser. For example, a server hosted on example.com cannot set cookie with anotherweb.com or foo.example.com.

Additionally, cookie header is optional and can be omitted. For example, it can be done by the browser’s privacy setting block cookies.

Cookie is not the only solution

Other than cookie, there are alternatives for maintaining a user’s state .

In RFC 6265 (the latest RFC), it mentions a few solutions other than cookie and points out the disadvantages of them:

Embed state information in URLs

It is unreliable. If user clicks the back button, the user will roll back to the previous state. It would be problematic for a shopping website if it adds or removes shopping cart items by changing the URL. If a user clicks the back button, he may accidentally add or remove an item.
Embedding state information in URL is unfriendly to web caches.
It may causes unexpected result if the client can edit the URL, which is sent to the server.

Use hidden fields in HTML forms

Same concern here. It may causes unexpected result if the client can edit the information which is sent to the server.

Use client’s Internet Protocol (IP) address

It is unreliable to identity user or computer based on its IP address. For example, if you use an HTTP Proxy, the server only knows the proxy’s IP address, instead of your computer’s. All of the proxy users will be treated as one user to a server. In addition, if you use a temporary IP address every time given by an ISP when you connect with it every time, you will appear to be a different user.

To avoid these disadvantages, cookie is a more friendly option for exchanging state information between server and client.

First-party cookie & third-party cookie

First-party cookie

Cookie created by the host domain. Normally first-party cookie helps improving user experience of the website. For example, first-party cookie helps tracking your shopping cart items or skip login pages if you have logged in before.

Third-party cookie

Third party cookie means cookie that is sent by a server which is not the connected by the user. For example, when you visit example.com, it may contain a JavaScript file from a different domain, ad.example.com . It sets cookie in its response to your browser, for tracking your actions on example.com , mainly for advertising purpose. By analysing your actions recorded by the cookie, advertising company can easily post Ads based on your interest.

Recent RFC suggests letting browsers to decide their own third-party cookie policy. By default, Google Chrome, Firefox allows setting third-party cookies but newer version Safari does not.

Be aware of the size of cookie

If the size of cookie is too large, it will slow down the connection. For example, if a website connects with multiple servers and each request contains a cookie. The total size of the cookies may slow down the connection.

Limitations of cookie

A browser can:

Support cookies with 4KB at maximum.
Support at least 50 cookies per domain.
Support at least 3000 cookies in total.

Summary

With session, client and server exchange user’s state information with cookie within a particular period of time.
Session-based authentication means authenticating a user by his session ID stored in cookie in his browser. The server retrieves his information by finding out the matching session ID stored in database.
Session ID is a unique id for each user. It is created in server and used for identifying user.
Server uses Set-cookie HTTP response header for setting cookie. Browser users Cookie header in HTTP request to send cookie to the server.
Browser bans cookie with domain attribute that does not match the domain of the host server.

This article summarises the basic concept of cookie, session and sessionID . The next article will discuss the security problems of cookie and session-based authentication.