# HTTP Cookie

## Summary


HTTP cookies are small bits of information exchanged between client and server over the HTTP protocol. The server sets these cookies. The client receives and saves them locally. Subsequently, whenever the client makes a request to the server, it includes these cookies in the request. The server uses these cookies to provide the desired services. 

Cookies are exchanged as simple strings in HTTP headers. Each cookie is a name-value pair. Cookies are scoped to the domain and web server path. Clients (formally called user agents) are typically web browsers. Often cookies are persistent even when browsers are closed. 

Cookies bring efficiency and convenience to the web browsing experience. However, cookies have been misused to track users (privacy) or hack systems (security).  These threats are being addressed by regulations and alternative technical solutions.

## Discussion

### What's the problem that an HTTP cookie solves?

HTTP protocol enables client-server communication on the web. HTTP itself is a **stateless protocol**. A server doesn't use information from previous requests to respond to the current request.

However, many scenarios require the server to maintain some state information about the client. For example, a user logs into Gmail. Subsequently, she may read emails, compose a new mail, add attachments or change her mail settings. Each of these is one or more independent HTTP requests. Without state, the server would have to authenticate the user with each request. Instead, authentication is done once, cookies are set, and cookies are exchanged in subsequent requests to identify the authenticated user.  In other words, cookies enable **stateful communication** on top of stateless HTTP. 

There are plenty of other examples where stateful communication is beneficial: adding items to a shopping cart on an e-commerce site, transferring money from one bank account to another, participating in an online Q&A forum, setting the language preference on a multilingual site, or searching where search engines use past queries to determine context.


### What are the main uses of HTTP cookies?

The way Google uses cookies gives us an insight into the different uses of cookies: 

    + **Preferences**: Remember a user's language preference or region. For example, this can be used to serve local weather or traffic reports. Users can also personalize font, text size or colours.
    + **Security**: Used to authenticate users and protect user data from unauthorized access.
    + **Processes**: Used to make the site work properly for the user. This includes navigation or protected access of certain resources. For example, many documents can be opened in Google Docs in the same browser.
    + **Advertising**: Serve personalized ads to user. For example, recent Google searches may be used to personalize ads.
    + **Session State**: Used to learn how user uses the site, which pages are frequently visited, or measure effectiveness of affiliate advertising.
    + **Analytics**: Collect site statistics to learn how users interact with the site, without identifying users individually.Broadly, we can group cookies into three categories: session management (login, shopping carts, game scores), personalization (preferences, themes, settings), and tracking (recording and analyzing user behaviour). 


### What are the different types of cookies?

In terms of validity, we can identify session cookies and permanent cookies. **Session cookies** are deleted once the browser is closed. **Permanent cookies** persist even when the browser is closed but can be set to expire after a specified datetime. Most permanent cookies persist for one or two years. Browser will delete them if user doesn't visit those sites before the cookies expire. 

In terms of domain, **first-party cookies** are cookies exchanged with the site currently being visited. **Third-party cookies** are cookies exchanged with another site that's different from the current site. This happens because the current site uses some content from the third-party site. 

While not exactly HTTP cookies, there are also **Flash cookies**. These may be exchanged by sites that use Flash plugins. They're often called "supercookies" since users can't easily delete them. Related to this are **Zombie cookies** that recreate automatically even if deleted. To make the web more secure, browsers will stop supporting Flash from end of 2020.  


### Could you explain first-party and third-party cookies?

Suppose a user visits the site *www.website.com*. This server will respond with the content. The content may contain links to or load resources from another server. For example, *ad.doubleclick.net* might provide ad services for the content publisher at *www.website.com*. Thus, the user sees the site's content plus ads from the ad server. 

Cookies set by *www.website.com* are called first-party cookies. Such cookies are often necessary for the correct working of the site or application. Users typically don't block these cookies. 

Cookies set by the third-party server are called third-party cookies. Third-party cookies can be misused since they can be used to track user behaviour across sites. For example, if the user visits another site that also uses the same third-party ad services, the ad service now knows that the user visited both the sites. Due to privacy concerns, some users block third-party cookies. 

Third-party cookies come from ad services, social media plugins, live chat popups, etc. In future, such cookies may become obsolete as newer technologies replace them. 


### What are some essentials on HTTP cookies?

Server sets an HTTP cookie using `Set-Cookie` response header. A single response can set multiple cookies but a single `Set-Cookie` header can set only one cookie. A cookie is basically of the form `name=value` followed by zero or more attribute name-value pairs. Pairs are separated by a semi-colon and whitespace. 

When a client sends a request, applicable cookies are sent in `Cookie` header. All cookies are sent in a single `Cookie` header. Cookie name-value pairs are separated by a semi-colon and whitespace. Attribute name-value pairs are not part of the request. The order in which the cookies appear in the header should not be significant to the server. 

Attributes may contain only the name and no value. Two attributes of this nature are `Secure` and `HttpOnly`. 

At the client-side, clients shall ignore unrecognized attributes but not the entire cookie. When a client receives the same cookie as an already stored cookie (with same domain and path attributes), the new cookie shall replace the old one. At the server-side, semantics are application-specific. 


### Could you describe the different attributes of a cookie?

Attribute names are recognized in a case-insensitive manner. These attributes can be optionally used for each HTTP cookie:  

    + **Expires**: Cookie expires at the specified datetime. Servers can delete an existing cookie by specifying a past datetime.
    + **Max-Age**: Specifies in seconds when cookie expires relative to current time.
    + **Domain**: Cookie is applicable to the specified domain and its subdomains. For example, with `Domain=example.com`, cookie will be sent with requests to both `example.com` and `beta.example.com`. If absent, cookie will be sent only to the origin server and not to subdomains.
    + **Path**: Specifies the applicable document path. For example, with `Path=/dashboard`, cookie will be sent for both `/dashboard` and `/dashboard/today` but not for `/posts`. For global cookie, use `Path=/`. If omitted, path defaults to current document location.
    + **Secure**: With this attribute, cookie is sent only over HTTPS connections.
    + **HttpOnly**: This makes the cookie inaccessible using `document.cookie` JavaScript API. Only the server can edit such a cookie.
    + **SameSite**: This mitigates the risk of Cross-Site Request Forgery (CSRF) attacks. With a suitable setting, client sends the cookie only to origin server and not to third-party servers.

### Could you explain the SameSite attribute?

SameSite cookie attribute can mitigate the risk of CSRF attacks. A typical CSRF attack is when you visit *evil.com* that then makes a cross-site request from your browser to your blog *myblog.com* to modify or even delete blog posts.  

SameSite cookie attribute takes one of three values:  

    + **Strict**: This is the most restrictive setting. Third-party cookies are ignored. While this is safe, it can also dampen user experience. For example, assume a user is already logged into a site *myblog.com*. User visits *example.com* where she clicks a link leading to her blog. Since cookies are not sent, the login will not be recognized until the user refreshes the page on her blog in a first-party context.
    + **Lax**: This relaxes the restriction from Strict mode. When the user follows the link, the browser will include the cookies. Cookies are included only with GET requests.
    + **None**: This is the most open setting but Secure attribute is mandatory. Third-party cookies are allowed. This means that if *example.com* were to request an image from *myblog.com*, third-party cookies would be sent, which doesn't happen for Lax mode.

### What are some shortcomings of HTTP cookies?

Cookies can only contain simple strings. They're not suited to handle complex data structures. Each cookie has a size limit of 4KB. Cookies can be edited or deleted by users at the client side. Applications must be designed to handle this. Cookies are not encrypted, which means that they're not suited to handle sensitive information. Any encryption must be provided by the application. Cookies can also "leak" from one browser tab to the next, creating unintended effects on the application. 

Since cookies are sent with every request, this has a performance impact, especially on slow mobile network connections. 

Privacy concerns of cookies are well known. Third-party cookies are widely used by ad networks and social networking sites to track users and assemble extensive profile of users in terms of behaviour and preferences. Via social engineering, they can also be used to hack into user accounts, servers and bank accounts. 

Modern solutions to avoid using cookies include Web Storage API or IndexedDB for storage; JSON Web Tokens for token-based authentication; and Google's Privacy Sandbox or Storage Access API for cross-origin requests. Fingerprinting could be used for tracking users. 


### Which are the standards relevant to HTTP cookies?

The main document is IETF's RFC 6265 titled *HTTP State Management Mechanism*. This defines what's a cookie and the Set-Cookie header fields. It describes server-side and client-side requirements. It also addresses implementation, privacy and security aspects. 

As on October 2020, **RFC 6265bis** was in draft form. It aims to update RFC 6265. Among its additions are cookie prefixes (`&lowbar;&lowbar;Secure-` and `&lowbar;&lowbar;Host-`) and SameSite attribute. 

The concept of origin is essential for cookies. **Origin** is defined in RFC 6454 titled *The Web Origin Concept*. 

Two relevant W3C Working Group Notes to look at are Tracking Preference Expression (DNT) and Tracking Compliance and Scope.

## Milestones

Oct  
1995

Netscape Communications Corp. files a US patent titled *Persistent client state in a hypertext transfer protocol based client-server system*. It describes, "… when a server responds to an http request by returning an HTTP object to a client, the server may also send a piece of state information that the client system will store. In an embodiment of the present invention, the state information is referred to as a 'cookie'." 

Feb  
1997

Cookies are described in detail in an IETF document **RFC 2109** titled *HTTP State Management Mechanism*. Subsequently, this RFC is superseded by **RFC 6265** (April 2011). 

2002

The European Union passes **ePrivacy Directive (EPD)**. This is amended in 2009 and again in 2017 at the direction of General Data Protection Regulation (GDPR). In time, EPD comes to be called the *Cookie Law*.  

Aug  
2012

Federal Trade Commission orders Google to pay a penalty of $22.5 million for placing **tracking cookies** in Apple's Safari browser. This violated a privacy agreement between FTC and Google. These cookies were placed by Google's DoubleClick advertising network and bypassed Safari's default setting of blocking third-party cookies. 

Jun  
2016

Details on **SameSite cookies** are published in an IETF draft that aims to update RFC 6265. This enables servers to assert that cookies should not be sent with cross-site requests. This mitigates the risk of cross-site request forgery (CSRF) attacks. This draft later becomes part of RFC 6265bis draft. 

Oct  
2016

Version 00 of **RFC 6265bis** is published. Version 06 of this Internet-Draft is published in April 2020. When eventually approved, this would supersede RFC 6265. 

Jun  
2017

**Intelligent Tracking Prevention (ITP)** is released as a new WebKit feature, where WebKit is the engine used in Safari web browser. ITP collects statistics about resource loads and user interactions. Via machine learning, it classifies if a domain is likely to do cross-site tracking. If so classified, it's cookies can't be used in third-party requests after 24 hours and are purged after 30 days. In March 2020, WebKit fully blocks third-party cookies. For cross-site integration, they propose **Storage Access API** as an alternative. 

May  
2018

First approved in April 2016, **General Data Protection Regulation (GDPR)** comes into effect. Any cookie that can identify individuals is considered personal data. Such cookies require a user's explicit consent. Simply using the site doesn't imply consent. Site should provide user a means to withdraw consent. User consent must be stored. Sites must clarify the purpose of each cookie and the data it collects. 

Jan  
2019

W3C publishes a working group note titled *Tracking Preference Expression*. Also called **Do Not Track (DNT)**, this gives users a means to express their preference with regard to tracking. When enabled, it's sent as a separate header with content `DNT:0` or `DNT:1`. If not enabled, servers can't assume users are saying yes to tracking. The earliest draft of this note can be traced to November 2011. 

Aug  
2019

Due to the privacy concerns surrounding third-party cookies, Google proposes a new initiative called **Privacy Sandbox**. This is a designed to protect user privacy while keeping content accessible on the web. They note that simply blocking third-party cookies is not effective since fingerprinting can still be used to identify users across websites; and unlike cookies, fingerprints can't be cleared. Moreover, blocking cookies denies publishers funding via ad revenues. Google Chrome plans to phase out third-party cookies by 2022. 

Feb  
2020

Google Chrome browser changes the default value for attribute SameSite from None to Lax. Cookies without the SameSite attribute will be treated as having `SameSite=Lax`. This restricts the use of third-party cookies in unsafe contexts. Mozilla brings a similar change to its Firefox browser in June (for some beta users only). In May 2019, this was proposed in an IETF draft titled *Incrementally Better Cookies*.