Cookies, document.cookie

Cookies are small strings of data that are stored directly in the browser. They are a part of the HTTP protocol, defined by the RFC 6265 specification. Cookies are usually set by a web server using the response Set-Cookie HTTP header. Then, the browser automatically adds them to (almost) every request to the same domain using the Cookie HTTP header. One of the most widespread use cases is authentication: 1. Upon sign-in, the server uses the Set-Cookie HTTP header in the response to set a cookie with a unique “session identifier”. 2. Next time the request is sent to the same domain, the browser sends the cookie over the net using the Cookie HTTP header. 3. So the server knows who made the request. We can also access cookies from the browser, using document.cookie property. There are many tricky things about cookies and their attributes. In this chapter, we’ll cover them in detail.

Reading from document.cookie

The value of document.cookie consists of name=value pairs, delimited by ; . Each one is a separate cookie. To find a particular cookie, we can split document.cookie by ; , and then find the right name. We can use either a regular expression or array functions to do that. We leave it as an exercise for the reader. Also, at the end of the chapter, you’ll find helper functions to manipulate cookies.

Writing to document.cookie

We can write to document.cookie. But it’s not a data property, it’s an accessor (getter/setter). An assignment to it is treated specially. A write operation to document.cookie updates only the cookie mentioned in it and doesn’t touch other cookies. For instance, this call sets a cookie with the name user and value John: If you run it, you will likely see multiple cookies. That’s because the document.cookie= operation does not overwrite all cookies. It only sets the mentioned cookie user. Technically, name and value can have any characters. To keep the valid formatting, they should be escaped using a built-in encodeURIComponent function: Cookies have several attributes, many of which are important and should be set. The attributes are listed after key=value, delimited by ;, like this:

domain

• domain=site.com A domain defines where the cookie is accessible. In practice though, there are limitations. We can’t set any domain. There’s no way to let a cookie be accessible from another 2nd-level domain, so other.com will never receive a cookie set at site.com. It’s a safety restriction, to allow us to store sensitive data in cookies that should be available only on one site. By default, a cookie is accessible only at the domain that set it. Please note, by default, a cookie is not shared with a subdomain, such as forum.site.com. …But this can be changed. If we’d like to allow subdomains like forum.site.com to get a cookie set at site.com, that’s possible. For that to happen, when setting a cookie at site.com, we should explicitly set the domain attribute to the root domain: domain=site.com. Then all subdomains will see such a cookie. For example: To summarize, the domain attribute allows to make a cookie accessible at subdomains.

  path

• path=/mypath The URL path prefix must be absolute. It makes the cookie accessible for pages under that path. By default, it’s the current path. If a cookie is set with path=/admin, it’s visible on pages /admin and /admin/something, but not at /home, /home/admin or /. Usually, we should set path to the root: path=/ to make the cookie accessible from all website pages. If this attribute is not set the default is calculated using this method.

  expires, max-age

  By default, if a cookie doesn’t have one of these attributes, it disappears when the browser/tab is closed. Such cookies are called “session cookies” To let cookies survive a browser close, we can set either the expires or max-age attribute. max-Age has precedence if both are set.

• expires=Tue, 19 Jan 2038 03:14:07 GMT The cookie expiration date defines the time when the browser will automatically delete it (according to the browser’s time zone). The date must be exactly in this format, in the GMT timezone. We can use date.toUTCString to get it. For instance, we can set the cookie to expire in 1 day: If we set expires to a date in the past, the cookie is deleted.

• max-age=3600 It’s an alternative to expires and specifies the cookie’s expiration in seconds from the current moment. If set to zero or a negative value, the cookie is deleted:

  secure

• secure The cookie should be transferred only over HTTPS. By default, if we set a cookie at http://site.com, then it also appears at https://site.com and vice versa. That is, cookies are domain-based, they do not distinguish between the protocols. With this attribute, if a cookie is set by https://site.com, then it doesn’t appear when the same site is accessed by HTTP, as http://site.com. So if a cookie has sensitive content that should never be sent over unencrypted HTTP, the secure flag is the right thing.

  samesite

  This is another security attribute samesite. It’s designed to protect from so-called XSRF (cross-site request forgery) attacks. To understand how it works and when it’s useful, let’s take a look at XSRF attacks.

  XSRF attack

  Imagine, you are logged into the site bank.com. That is: you have an authentication cookie from that site. Your browser sends it to bank.com with every request so that it recognizes you and performs all sensitive financial operations. Now, while browsing the web in another window, you accidentally come to another site evil.com. That site has JavaScript code that submits a form

  to bank.com with fields that initiate a transaction to the hacker’s account. The browser sends cookies every time you visit the site bank.com, even if the form was submitted from evil.com. So the bank recognizes you and performs the payment. This is a so-called “Cross-Site Request Forgery” (in short, XSRF) attack. Real banks are protected from it of course. All forms generated by bank.com have a special field, a so-called “XSRF protection token”, that an evil page can’t generate or extract from a remote page. It can submit a form there, but can’t get the data back. The site bank.com checks for such a token in every form it receives. Such a protection takes time to implement though. We need to ensure that every form has the required token field, and we must also check all requests.

  Use cookie samesite attribute

  The cookie samesite attribute provides another way to protect from such attacks, that (in theory) should not require “xsrf protection tokens”. It has two possible values:

• samesite=strict A cookie with samesite=strict is never sent if the user comes from outside the same site. In other words, whether a user follows a link from their email, submits a form from evil.com, or does any operation that originates from another domain, the cookie is not sent. If authentication cookies have the samesite=strict attribute, then an XSRF attack has no chance of succeeding, because a submission from evil.com comes without cookies. So bank.com will not recognize the user and will not proceed with the payment. The protection is quite reliable. Only operations that come from bank.com will send the samesite=strict cookie, e.g. a form submission from another page at bank.com. Although, there’s a small inconvenience. When a user follows a legitimate link to bank.com, like from their notes, they’ll be surprised that bank.com does not recognize them. Indeed, samesite=strict cookies are not sent in that case. We could work around that by using two cookies: one for “general recognition”, only to say: “Hello, John”, and the other one for data-changing operations with samesite=strict. Then, a person coming from outside of the site will see a welcome, but payments must be initiated from the bank’s website, for the second cookie to be sent.

• samesite=lax (same as samesite without value) A more relaxed approach that also protects from XSRF and doesn’t break the user experience. Lax mode, just like strict, forbids the browser to send cookies when coming from outside the site, but adds an exception. A samesite=lax cookie is sent if both of these conditions are true:

1. The HTTP method is “safe” (e.g. GET, but not POST). The full list of safe HTTP methods is in the RFC7231 specification. These are the methods that should be used for reading, but not writing the data. They must not perform any data-changing operations. Following a link is always GET, the safe method.
2. The operation performs a top-level navigation (changes URL in the browser address bar). This is usually true, but if the navigation is performed in an