HTTP - Cookie (Set-Cookie Header )

> (World Wide) Web - (W3|WWW) > (HTTP|HTTPS) - Hypertext Transfer Protocol

1 - About

A cookie is a key-value data and some associated metadata

It is:

In a nutshell, a cookie is a mechanism:

The (HTTP Cookie and Set-Cookie) header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol.

Advertising

3 - Example

  • HTTPS
Set-Cookie: sessionCookieKeyName=de73c7e08a3753ac6b2fc84a838098dd91524036568; expires=Thu, 18-Apr-19 07:29:28 GMT; path=/; domain=.example.com; HttpOnly; Secure
  • HTTP
Set-Cookie: sessionCookieKeyName=dbed136878a72f4a881e70c74fcf4b3411524036444; expires=Thu, 18-Apr-19 07:27:24 GMT; path=/; domain=.example.com; HttpOnly

where: sessionCookieKeyName is a Web Security - Session Cookie

4 - Properties

4.1 - Name

The cookie's name.

4.2 - Value

The cookie's value.

4.3 - Metadata

4.3.1 - Scope

The scope indicates:

  • the servers to which the user agent should return the cookie,
  • and the URI schemes for which the cookie is applicable.

The server can alter the default scope of the cookie using the Path and Domain attributes.

Example:

  • A cookie set by the server that should be return to every path and every subdomain of example.com.
Set-Cookie: key=value; Path=/; Domain=example.com
Advertising
4.3.1.1 - Domain

HTTP - Domain value of a Cookie - The hosts that are allowed to receive the cookie.

4.3.1.2 - Path
  • “/” - all paths including the root will be able to read the cookie
  • example.com/user-1-blog and example.com/user-2-blog which should not share cookie with this path

4.3.2 - Expiration Date

If the server wishes the user agent to persist the cookie over multiple “sessions” (e.g., user agent restarts), the server can specify an expiration date via:

If a cookie has both the Max-Age and the Expires attribute, the Max-Age attribute has precedence and controls the expiration date of the cookie.

If a cookie has neither the Max-Age nor the Expires attribute, the user agent will retain the cookie until “the current session is over” (ie Restart of the browser).

4.3.2.1 - expires

expires example:

Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT

An expires with a date in the past will remove the cookie.

Advertising
4.3.2.2 - max-Age

The Max-Age attribute indicates the maximum lifetime of the cookie, represented as the number of seconds until the cookie expires.

4.3.3 - HttpOnly

The HttpOnly flag tells the browser that this particular cookie should only be accessed by the server (not by the client)

4.3.4 - Secure

When a cookie has the Secure attribute, the user agent (browser) will include the cookie only if the request is transmitted over a secure channel (typically HTTPS (HTTP over Transport Layer Security)).

4.3.5 - SameSite

SameSite value:

  • Strict
  • Lax
  • None

Assert if a cookie must not be sent with cross-origin requests (to providing protection against cross-site request forgery attacks (CSRF))

SameSite cookie (née “First-Party-Only” (née “First-Party”)) allow servers to mitigate the risk of CSRF and information leakage attacks by asserting that a particular cookie should only be sent with requests initiated from the same registrable domain.

More:

5 - Usage

5.1 - Identify Individual

Cookies often store behavioral information.

Cookies are the preferred way for servers to track sessions. The server supplies a cookie, in response to a request. The server expects the client to send that piece of data in a header field with each following request of the same session. The cookie is different for each session, so the server can identify to which session a request belongs by looking at the cookie.

Cookie helps to identify individual clients (without been authenticated) behind a shared IP address (HotSpot, Proxy, Vpn, …) and apply functionality on a per-client basis (security,…).

To keep anonymity and to not be able to personally identified the client, the End User IP addresses (user-level data) should be stored as a one-way hash.

This sort of cookie are session cookie with an expiration duration generally of 30 days.

Tracking: The user cookie is updated with a new expires date and re-sent on every response, extending the lifetime out.

if (request contains an id cookie) {
    Record that cookie as the user identifier
    Set that cookie with a now+1 year cookie expiry
} else {
    Set the id cookie with a now+1 year cookie expiry
}

5.2 - Authentication

Identifying an individual is not always bad as you need to authenticate a user. Cookies are the most common way to authenticate an individual and to give him some authorization (access to a backend, etc…).

See Web Security - Session Cookie

5.3 - Cross-site tracking

You can follow users from site to site by merging various cookie identifiers into a profile. See Cross-site tracking

5.4 - Bad Bot Protection

A cookie may be used in bad bot protection.

When identifying an activity as a potential bad bot activity:

  • the user is presented with a challenge. If the End User passes the challenge, a session cookie prevents additional challenges for up to generally 30 minutes.
  • a cookie is send and as generally the bot application does not manage the cookie, the cookie is not send back and may help in bad activity detection.

5.5 - Load Balancer Session Affinity

On a load balancer, you may want to send every request of the same user session to the same node.

For this purpose, a session cookie can be used to create a session (max 24 hours) and route all future requests of this session to the same origin (same server in the cluster).

This is important when you are keeping user data on the server side.

For instance, suppose that you store a shopping cart on the server side. Without session affinity, every user action will be redirected to another server (node) in the cluster. You may seen this kind of sequence:

  • the user adds an item, the load balancer sends it to the server A that stores it locally
  • the user want to see its shopping card, the load balancer sends it to the server B. The server B cannot see items from the server A and therefore the user don't see any items in the shopping cart.

In the event of a failover, a new session cookie should be created.

6 - Security

When you tag a cookie with the HttpOnly flag, this cookie can not be accessed by the browser but only by the server.

Example:

Set-Cookie: user=t=bfabf0b1c1133a822; path=/; HttpOnly

For historical reasons, cookies contain a number of security and privacy infelicities.

For example:

  • a server can indicate that a given cookie is intended for “secure” connections, but the Secure attribute does not provide integrity in the presence of an active network attacker.
  • cookies for a given host are shared across all the ports on that host, even though the usual same-origin policy used by web browsers isolates content retrieved via different ports.

7 - Management

You can manage cookie:

7.1 - Set / Get

set-cookie: SERVERID108284=104011; path=/; max-age=900

7.2 - Delete

To remove a cookie:

programmatically, the cookie must be set with an expiration date in the past.

set-cookie: DW7fa065a06cb74b536c124cfbe56ac6d3=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; secure; HttpOnly

manually

8 - Specification

9 - Documentation / Reference