What is a Cookie? (HTTP Set-Cookie Header )


A cookie is:

The received cookies by the browser can be seen in their devtool

Chrome Cookies


With the Set-Cookie header, we can create the following 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 .example.com
  • 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=/; domain=.example.com; HttpOnly; Secure

Cookie: session=de73c7e08a3753ac6b2f; expires=Thu, 18-Apr-19 07:29:28 GMT; path=/; domain=.example.com; HttpOnly; Secure

A cookie 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 stateless HTTP protocol.


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.

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

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

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

A tracking cookie does not track a session but a user.

The user cookie is updated with a new expiration 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"

For more information, see this dedicated page: How does a tracking cookie work? A step by step example

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


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

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 foo.example.com server can create / set a cookie with a Domain attribute of example.com:

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



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


See Cookie - Scope


See Cookie - Scope


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

More see How is the Cookie Expiration date calculated? (max-age)


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

More see How is the Cookie Expiration date calculated? (max-age)


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

See What is the SameSite Cookie property? First-Party and third-party cookie control


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:

Chrome Cookies



Why I don't see my cookies on the Application tab?

On the application tab, you will see only the cookies that have been sent with a request from the browser. If you want to see the cookie received with a request, check the cookie tab on the request details of the network tab.

Chrome Cookies

Check in the devtool that the domain of the cookie is the same as 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

Set Cookie Block Bad Domain Att Vs Current Host Url

In the devtool (F12), go to:

  • Network
  • Request
  • Cookie tab

You will see the cookies send and received.

Chrome Dev Tool Chrome Filtered Out Cookies

Documentation / Reference

Discover More
Card Puncher Data Processing
Ad - Consumer (Customer, Visitor)

A consumer is a customer in the ad world. Consumers are not personally identifiable to the ecosystem. Instead, a limited amount of anonymous data, or non-personally identifiable data, is passed between...
Card Puncher Data Processing
Ads - Consent Management (CM - CMP)

Consent Management is a mandatory privacy process due to gdpr where a website showing a page to a EU resident needs the consent of the user in order to use their data (cookies,..) The consent box may...
Browser - Storage (Client Side Data)

This page is client side data (ie stateless session) in the browser. cookie local storage WebStorage - name/value pairs - Method of storing data locally...
Chrome Devtool Xhr Fetch Request
Browser - Web API - Fetch function

The fetch function is part of the web api function and is a AJAX call. It's one of the possibilities to fetch a resource. XMLHttpRequest (XHR) The fetch function returns a promise as response. The Fetch...
Cookie Scope Name
Cookie - Scope

The scope of a cookie name is a calculated property defined by the concatenation of the and attributes. If the request URL matches the scope (ie domain and path expression), the user agent (browser)...
First Party Cookie

A first party cookie is a cookie that is created by the domain that the user is visiting. If the code used is: yours, it's a first party script not yours, it's a third party script When a user...
Card Puncher Data Processing
Google Analytics - Utmb cookie

The Utmb cookie is one of the Ga cookie that fulfill the role of session cookie It's used to determine new sessions/visits. The cookie is created when the javascript library executes and it does...
HTML - Privacy (Anonymization)

in the HTML context. A user can be distinguished from another by the user's IP address. (IP addresses are not a perfectly match to a user due to routing, proxy, ...); Technologies such as onion...
Fiddler Web Debugger
HTTP - Fiddler

Fiddler is a HTTP Network Analyzer via a forward proxy It will install itself as the system HTTP Forward proxy. Browsers support the system proxy (ie windows configuration). You have nothing to...
Chrome Devtool Har
HTTP - Request

An HTTP request is a message sent from a client to a server. It's the first part of a fetch, the second being the response. A request message has: a first line called the request...

Share this page:
Follow us:
Task Runner