HTTP - Cookie (Set-Cookie Header )


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.


A session cookie with:

  • the name session,
  • the value de73c7e08a3753ac6b2f
  • that should be deleted at Thu, 18-Apr-19 07:29:28 GMT
  • that is send for all path / of the domain
  • that should not be accessible to javascript (ie httponly)
  • and should be send only over HTTPS because of its secure property
Set-Cookie: session=de73c7e08a3753ac6b2f; expires=Thu, 18-Apr-19 07:29:28 GMT; path=/;; HttpOnly; Secure



The cookie's name.


The cookie's value.


All below cookies properties defined when and if the cookie should be added to the request via the cookies header created by the user agent (ie browser).




max-age is a property that is part of the expiration date calculation

More see Cookie - Expiration


Expires is a property that is part of the expiration date calculation

More see Cookie - Expiration


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

In other words, if this flag is on, the javascript cookie web api cannot read the cookie


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)).


The SameSite cookie parameters control if the cookie should only be sent with requests initiated from the same registrable domain.

See Web HTTP - SameSite Cookie property (First-Party-Only)


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


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 Identifier Cookie

Cross-site tracking

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

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.

AB Testing

Cookie are used to set the bucket to a user when running an A/B testing.

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.

Security Considerations


When the browser makes a request (img, form), the cookies are by default send even if the request comes from another page on another domain.

This means that if you set a cookie on your website that identifies you, a malicious request created from another page will also get this cookies and produces a valid request in your name. This attack is know as Cross-site Request Forgery


When you tag a cookie with the HttpOnly flag, this cookie can not be accessed by the browser api. (ie it's only added in request to the server)


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.

First party vs Third Party

If the domain property of the cookie is the same as the domain of the page shown in the address bar of the web browser:

  • this is a First-party cookies (ie cookie created by the site you visit)
  • otherwise they are Third-party cookies (ie cookie created by other sites. These sites own some of the content, like ads or images, that you see and was included on the webpage you visit.)

Weak Integrity

Cookie value and properties can be changed easily.

This risks can be mitigated by encrypting and signing the contents of the cookies.

No Isolation by Port and Scheme

Cookies are isolated by scope (and not by origin).

Because the scope syntax does not contain the port nor the scheme

  • If a cookie is readable by a service running on one port, the cookie is also readable by a service running on another port (scheme) of the same server.
  • If a cookie is writable by a service running on one port, the cookie is also writable by a service running on another port (scheme) of the same server.

ie A site running on the http (port 80) can set a cookie for a site running on https (port 443).

Subdomain Overwriting

The server can create / set a cookie with a Domain attribute of

  • even if a previous cookie was created by,
  • and the user agent will include/send also that cookie in HTTP requests to


You can manage cookie:


Server Side

  • Receiving a request, the cookies can be read with the Cookies header
Cookies: SERVERID108284=104011
  • Sending a response, the cookies can be set/created with the Set-Cookie header
set-cookie: SERVERID108284=104011; path=/; max-age=900
set-cookie: DW7fa065a06cb74b536c124cfbe56ac6d3=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; secure; HttpOnly


Client Side:



Check in the devtool that the domain of the cookie is the same than the domain of the URL.

If you get the below error message correct the domain send with your cookie.

This set-cookie was blocked because its Domain attribute was invalid with regards to the current host url

Documentation / Reference

Powered by ComboStrap