docs.rodeo

MDN Web Docs mirror

Using HTTP cookies

{{HTTPSidebar}} 

A cookie (also known as a web cookie or browser cookie) is a small piece of data a server sends to a user’s web browser. The browser may store cookies, create new cookies, modify existing ones, and send them back to the same server with later requests. Cookies enable web applications to store limited amounts of data and remember state information; by default the HTTP protocol is stateless.

In this article we will explore the main uses of cookies, explain best practices for using them, and look at their privacy and security implications.

What cookies are used for

Typically, the server will use the contents of HTTP cookies to determine whether different requests come from the same browser/user and then issue a personalized or generic response as appropriate. The following describes a very simple user sign-in system:

  1. The user sends sign-in credentials to the server, for example via a form submission.
  2. If the credentials are correct, the server updates the UI to indicate that the user is signed in, and responds with a cookie containing a session ID that records their sign-in status on the browser.
  3. At a later time, the user moves to a different page on the same site. The browser sends the cookie containing the session ID along with the corresponding request to indicate that it still thinks the user is signed in.
  4. The server checks the session ID and, if it is still valid, sends the user a personalized version of the new page. If it is not valid, the session ID is deleted and the user is shown a generic version of the page (or perhaps shown an “access denied” message and asked to sign in again).

visual representation of the above sign-in system description

Cookies are mainly used for three purposes:

Data storage

In the early days of the web when there was no other option, cookies were used for general client-side data storage purposes. Modern storage APIs are now recommended, for example the Web Storage API (localStorage and sessionStorage) and IndexedDB.

They are designed with storage in mind, never send data to the server, and don’t come with other drawbacks of using cookies for storage:

[!NOTE] To see stored cookies (and other storage that a web page is using) you can use the Storage Inspector in Firefox Developer Tools, or the Application panel in Chrome Developer Tools.

Creating, removing, and updating cookies

After receiving an HTTP request, a server can send one or more {{HTTPHeader("Set-Cookie")}}  headers with the response, each one of which will set a separate cookie. A simple cookie is set by specifying a name-value pair like this:

Set-Cookie: <cookie-name>=<cookie-value>

The following HTTP response instructs the receiving browser to store a pair of cookies:

HTTP/2.0 200 OK
Content-Type: text/html
Set-Cookie: yummy_cookie=chocolate
Set-Cookie: tasty_cookie=strawberry

[page content]

[!NOTE] Find out how to use the Set-Cookie header in various server-side languages/frameworks: PHP, Node.js, Python, Ruby on Rails.

When a new request is made, the browser usually sends previously stored cookies for the current domain back to the server within a {{HTTPHeader("Cookie")}}  HTTP header:

GET /sample_page.html HTTP/2.0
Host: www.example.org
Cookie: yummy_cookie=chocolate; tasty_cookie=strawberry

You can specify an expiration date or time period after which the cookie should be deleted and no longer sent. Depending on the attributes set within the {{HTTPHeader("Set-Cookie")}}  header when the cookies are created, they can be either permanent or session cookies:

There are some techniques designed to recreate cookies after they’re deleted. These are known as “zombie” cookies. These techniques violate the principles of user privacy and control, may violate data privacy regulations, and could expose a website using them to legal liability.

To update a cookie via HTTP, the server can send a {{HTTPHeader("Set-Cookie")}}  header with the existing cookie’s name and a new value. For example:

Set-Cookie: id=new-value

There are several reasons why you might want to do this, for example if a user has updated their preferences and the application wants to reflect the changes in client-side data (you could also do this with a client-side storage mechanism such as Web Storage).

Updating cookies via JavaScript

In the browser, you can create new cookies via JavaScript using the {{domxref("Document.cookie")}}  property, or the asynchronous {{domxref("Cookie_Store_API", "Cookie Store API", "", "nocode")}} . Note that all examples below use Document.cookie, as it is the most widely supported/established option.

document.cookie = "yummy_cookie=chocolate";
document.cookie = "tasty_cookie=strawberry";

You can also access existing cookies and set new values for them, provided the HttpOnly attribute isn’t set on them (i.e. in the Set-Cookie header that created it):

console.log(document.cookie);
// logs "yummy_cookie=chocolate; tasty_cookie=strawberry"

document.cookie = "yummy_cookie=blueberry";

console.log(document.cookie);
// logs "tasty_cookie=strawberry; yummy_cookie=blueberry"

Note that, for security purposes, you can’t change cookie values by sending an updated Cookie header directly when initiating a request, i.e. via {{domxref("Window/fetch", "fetch()")}}  or {{domxref("XMLHttpRequest")}} . Note that there are also good reasons why you shouldn’t allow JavaScript to modify cookies — i.e. set HttpOnly during creation. See the Security section for more details.

Security

When you store information in cookies, by default all cookie values are visible to, and can be changed by, the end user. You really don’t want your cookies to be misused — for example accessed/modified by bad actors, or sent to domains where they shouldn’t be sent. The potential consequences can range from annoying — apps not working or exhibiting strange behavior — to catastrophic. A criminal could for example steal a session ID and use it to set a cookie that makes it look like they are logged in as someone else, taking control of their bank or e-commerce account in the process.

You can secure your cookies in a variety of ways, which are reviewed in this section.

Block access to your cookies

You can ensure that cookies are sent securely and aren’t accessed by unintended parties or scripts in one of two ways: with the Secure attribute and the HttpOnly attribute:

Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly

[!NOTE] Depending on the application, you may want to use an opaque identifier that the server looks up rather than storing sensitive information directly in cookies, or investigate alternative authentication/confidentiality mechanisms such as JSON Web Tokens.

Define where cookies are sent

The Domain and Path attributes define the scope of a cookie: what URLs the cookies are sent to.

Controlling third-party cookies with SameSite

The SameSite attribute lets servers specify whether/when cookies are sent with cross-site requests — i.e. third-party cookies. Cross-site requests are requests where the {{Glossary("Site", "site")}}  (the registrable domain) and/or the scheme (http or https) do not match the site the user is currently visiting. This includes requests sent when links are clicked on other sites to navigate to your site, and any request sent by embedded third-party content.

SameSite helps to prevent leakage of information, preserving user privacy and providing some protection against {{Glossary("CSRF", "cross-site request forgery")}}  attacks. It takes three possible values: Strict, Lax, and None:

If no SameSite attribute is set, the cookie is treated as Lax by default.

Because of the design of the cookie mechanism, a server can’t confirm that a cookie was set from a secure origin or even tell where a cookie was originally set.

A vulnerable application on a subdomain can set a cookie with the Domain attribute, which gives access to that cookie on all other subdomains. This mechanism can be abused in a session fixation attack. See session fixation for primary mitigation methods.

As a defense-in-depth measure, however, you can use cookie prefixes to assert specific facts about the cookie. Two prefixes are available:

The browser will reject cookies with these prefixes that don’t comply with their restrictions. This ensures that subdomain-created cookies with prefixes are either confined to a subdomain or ignored completely. As the application server only checks for a specific cookie name when determining if the user is authenticated or a CSRF token is correct, this effectively acts as a defense measure against session fixation.

[!NOTE] On the server, the web application must check for the full cookie name including the prefix. User agents do not strip the prefix from the cookie before sending it in a request’s {{HTTPHeader("Cookie")}}  header.

For more information about cookie prefixes and the current state of browser support, see the Prefixes section of the Set-Cookie reference article.

Privacy and tracking

Earlier on we talked about how the SameSite attribute can be used to control when third-party cookies are sent, and that this can help preserve user privacy. Privacy is a very important consideration when building websites which, when done right, can build trust with your users. If done badly, it can completely erode that trust and cause all kinds of other problems.

Third-party cookies can be set by third-party content embedded in sites via {{htmlelement("iframe")}} s. They have many legitimate uses include sharing user profile information, counting ad impressions, or collecting analytics across different related domains.

However, third-party cookies can also be used to create creepy, invasive user experiences. A third-party server can create a profile of a user’s browsing history and habits based on cookies sent to it by the same browser when accessing multiple sites. The classic example is when you search for product information on one site and are then chased around the web by adverts for similar products wherever you go.

Browser vendors know that users don’t like this behavior, and as a result have all started to block third-party cookies by default, or at least made plans to go in that direction. Third-party cookies (or just tracking cookies) may also be blocked by other browser settings or extensions.

[!NOTE] Cookie blocking can cause some third-party components (such as social media widgets) not to function as intended. As browsers impose further restrictions on third-party cookies, developers should start to look at ways to reduce their reliance on them.

See our Third-party cookies article for detailed information on third-party cookies, the issues associated with them, and what alternatives are available. See our Privacy landing page for more information on privacy in general.

Legislation or regulations that cover the use of cookies include:

These regulations have global reach. They apply to any site on the World Wide Web that users from these jurisdictions access (the EU and California, with the caveat that California’s law applies only to entities with gross revenue over 25 million USD, among things).

These regulations include requirements such as:

There may be other regulations that govern the use of cookies in your locality. The burden is on you to know and comply with these regulations. There are companies that offer “cookie banner” code that helps you comply with these regulations.

[!NOTE] Companies should disclose the types of cookies they use on their sites for transparency purposes and to comply with regulations. For example, see Google’s notice on the types of cookies it uses and Mozilla’s Websites, Communications & Cookies Privacy Notice.

See also

In this article

View on MDN