How to get to cookies

Куки, document.cookie

Куки – это небольшие строки данных, которые хранятся непосредственно в браузере. Они являются частью HTTP-протокола, определённого в спецификации RFC 6265.

Один из наиболее частых случаев использования куки – это аутентификация:

Куки имеют множество особенностей и тонкостей в использовании, и в этой главе мы подробно с ними разберёмся.

Чтение из document.cookie

Хранит ли ваш браузер какие-то куки с этого сайта? Посмотрим:

Оставим эту задачу читателю для самостоятельного выполнения. Кроме того, в конце этой главы вы найдёте полезные функции для работы с куки.

Запись в document.cookie

Запись в document.cookie обновит только упомянутые в ней куки, но при этом не затронет все остальные.

Например, этот вызов установит куки с именем user и значением John :

Технически, и имя и значение куки могут состоять из любых символов, для правильного форматирования следует использовать встроенную функцию encodeURIComponent :

Существует несколько ограничений:

У куки есть ряд настроек, многие из которых важны и должны быть установлены.

URL-префикс пути, куки будут доступны для страниц под этим путём. Должен быть абсолютным. По умолчанию используется текущий путь.

domain

Домен определяет, где доступен файл куки. Однако на практике существуют определённые ограничения. Мы не можем указать здесь какой угодно домен.

Это ограничение безопасности, позволяющее нам хранить конфиденциальные данные в файлах куки, которые должны быть доступны только на одном сайте.

По умолчанию куки доступны лишь тому домену, который его установил.

По историческим причинам установка domain=.site.com (с точкой перед site.com ) также работает и разрешает доступ к куки для поддоменов. Это старая запись, но можно использовать и её, если нужно, чтобы поддерживались очень старые браузеры.

Таким образом, опция domain позволяет нам разрешить доступ к куки для поддоменов.

expires, max-age

По умолчанию, если куки не имеют ни одного из этих параметров, то они удалятся при закрытии браузера. Такие куки называются сессионными («session cookies»).

Дата истечения срока действия куки, когда браузер удалит его автоматически.

Если мы установим в expires прошедшую дату, то куки будет удалено.

Если задан ноль или отрицательное значение, то куки будет удалено:

secure

Куки следует передавать только по HTTPS-протоколу.

То есть, куки, по умолчанию, опираются на доменное имя, они не обращают внимания на протоколы.

samesite

Это ещё одна настройка безопасности, применяется для защиты от так называемой XSRF-атаки (межсайтовая подделка запроса).

Чтобы понять, как настройка работает и где может быть полезной, посмотрим на XSRF-атаки.

Атака XSRF

Такая атака называется межсайтовая подделка запроса (или Cross-Site Request Forgery, XSRF).

Конечно же, в реальной жизни банки защищены от такой атаки. Во всех сгенерированных сайтом bank.com формах есть специальное поле, так называемый «токен защиты от xsrf», который вредоносная страница не может ни сгенерировать, ни каким-либо образом извлечь из удалённой страницы (она может отправить форму туда, но не может получить данные обратно). И сайт bank.com при получении формы проверяет его наличие.

Но такая защита требует усилий на её реализацию: нам нужно убедиться, что в каждой форме есть поле с токеном, также мы должны проверить все запросы.

Настройка samesite

Параметр куки samesite предоставляет ещё один способ защиты от таких атак, который (теоретически) не должен требовать «токенов защиты xsrf».

У него есть два возможных значения:

Куки с samesite=strict никогда не отправятся, если пользователь пришёл не с этого же сайта.

Другими словами, если пользователь переходит по ссылке из почты, отправляет форму с evil.com или выполняет любую другую операцию, происходящую с другого домена, то куки не отправляется.

Хотя есть небольшие неудобства.

Это более мягкий вариант, который также защищает от XSRF и при этом не портит впечатление от использования сайта.

Куки с samesite=lax отправляется, если два этих условия верны:

Используются безопасные HTTP-методы (например, GET, но не POST).

Полный список безопасных HTTP-методов можно посмотреть в спецификации RFC7231. По сути, безопасными считаются методы, которые обычно используются для чтения, но не для записи данных. Они не должны выполнять никаких операций на изменение данных. Переход по ссылке является всегда GET-методом, то есть безопасным.

Операция осуществляет навигацию верхнего уровня (изменяет URL в адресной строке браузера).

Но что-то более сложное, например, сетевой запрос с другого сайта или отправка формы, теряет куки.

В целом, samesite отличная настройка.

Но у неё есть важный недостаток:

Но мы, безусловно, можем использовать samesite вместе с другими методами защиты, такими как XSRF-токены, чтобы добавить дополнительный слой защиты, а затем, в будущем, когда старые браузеры полностью исчезнут, мы, вероятно, сможем полностью удалить XSRF-токены.

httpOnly

Эта настройка не имеет ничего общего с JavaScript, но мы должны упомянуть её для полноты изложения.

Эта настройка используется в качестве меры предосторожности от определённых атак, когда хакер внедряет свой собственный JavaScript-код в страницу и ждёт, когда пользователь посетит её. Это вообще не должно быть возможным, хакер не должен быть в состоянии внедрить свой код на ваш сайт, но могут быть ошибки, которые позволят хакеру сделать это.

Приложение: Функции для работы с куки

Для этого существует множество библиотек, так что они, скорее, в демонстрационных целях. Но при этом полностью рабочие.

getCookie(name)

Самый короткий способ получить доступ к куки – это использовать регулярные выражения.

Функция getCookie(name) возвращает куки с указанным name :

Обратите внимание, значение куки кодируется, поэтому getCookie использует встроенную функцию decodeURIComponent для декодирования.

setCookie(name, value, options)

deleteCookie(name)

Чтобы удалить куки, мы можем установить отрицательную дату истечения срока действия:

Обратите внимание: когда мы обновляем или удаляем куки, нам следует использовать только такие же настройки пути и домена, как при установке куки.

Приложение: Сторонние куки

Куки называются сторонними, если они размещены с домена, отличающегося от страницы, которую посещает пользователь.

В следующий раз при доступе к ads.com удалённый сервер получит куки id и распознает пользователя:

Сторонние куки в силу своей специфики обычно используются для целей отслеживания посещаемых пользователем страниц и показа рекламы. Они привязаны к исходному домену, поэтому ads.com может отслеживать одного и того же пользователя на разных сайтах, если оттуда идёт обращение к нему.

Естественно, некоторым пользователям не нравится, когда их отслеживают, поэтому браузеры позволяют отключать такие куки.

Кроме того, некоторые современные браузеры используют специальные политики для таких куки:

Если мы загружаем скрипт со стороннего домена, например

Комментарии

How to Get Cookies Using JavaScript

Cookies make it possible to store information about a web application’s user between requests.

After a web server sends a web page to a browser, the connection shuts down and all information held by the server is lost. This means that information cannot easily be persisted between requests, as at each new request the server will not have any local context on the user. Cookies overcome this obstacle by storing the required information on the user’s computer in the form of a name=value string.

Cookies are often used to store usernames, preferences, access passwords, etc.

Note: You should always keep security in mind when storing sensitive information like passwords. The information stored in cookies is stored as a plain string, and can be easily discovered with minimal technical knowledge.

To learn more about cookies check out this link.

Get cookies

Getting all of the cookies from a user’s machine is very simple. Just call document.cookie to retrieve the current value of all cookies. You can then store this value in a variable for further manipulation.

In the above code, the first two lines of code set the values of two different cookies – username, and userId. The third line retrieves both cookies and stores it to a variable named cookies.

To learn more about cookies, and setting a cookie, check out this link.

Get a cookie

Getting a specific cookie is a little more complex than retrieving all cookies, but not that big of a deal.

If you have the cookie’s name, all you need is a function that iterates through all of the user’s cookies and finds the specific cookie required. The code sample below defines a function, getCookie(), that takes the name of a cookie and returns that cookie’s value:

Exploring function getCookie() by line

The function getCookie takes a cookie’s name as a parameter, then performs the following steps:

Keep in mind that in many cases, working with cookies will begin with fetching a cookie’s value, and then requesting information from the user if the requested cookie is not found. The final result of the user’s input will be stored back to the user’s cookies. To learn more about cookies, and setting a cookie, visit this link.

How to create and read cookies in JavaScript

An HTTP cookie (also known as web cookie, browser cookie) is a small piece of information stored by the server in the user’s browser. Cookies are commonly used for session management, user-tracking, and storing user preferences.

In JavaScript, you can use the document.cookie property to create, read, and delete cookies. Note that the document.cookie property can only access cookies with the HttpOnly attribute unspecified.

Creating a Cookie

To create a new cookie in JavaScript, assign a name=value string to document.cookie :

Since the cookie value can not contain semicolons, commas, or spaces, you need the encodeURIComponent() function to encode the value before storing it in the cookie:

Cookie Expiration Date

By default, the above cookie lifespan is the current browser session, which means that it is removed when the user closes the browser. Such cookies are called session cookies.

To persist cookies beyond the current browser session, you need to specify its expiry date either using the expires attribute (in UTC/GMT format) or the max-age attribute (in seconds):

Cookie Path

By default, a cookie is available to all web pages in the same directory and its subdirectories. However, you can explicitly specify a path attribute to ensure that the cookie is only accessible to that path and its subdirectories.

Cookie Domain

The cookies, by default, are available only to the web pages in the domain they were used to set in. However, you can use the domain attribute to make a cookie available across subdomains.

Secure Cookie

You can also make a cookie secure using the secure attribute. Such cookies are only transmitted over a secure (i.e. encrypted) connection such as HTTPS:

Finally, let us write a JavaScript function that takes in the name, value, expiry days, path, and domain, and adds an HTTP cookie:

Now to set a cookie that lasts 3 months, use the following code:

Reading a Cookie

The document.cookie property returns all cookies set by the server as a series of key-value pairs separated by semi-colons:

Since all the values and names are URL-encoded, you have to decode them using the decodeURIComponent() method.

Let us write a function that takes the cookie name as input and returns its value. If the cookie is not found, it should return a null value.

The above code uses the JavaScript split() method to split the cookie string by semi-colon. Then it iterates through the result array to match the name of the requested cookie with the key-value pairs.

Updating a Cookie

You can update a cookie in the same way as you create it with the same name, path, domain, and secure option:

Alternatively, you could also use the above setCookie() function:

Deleting a Cookie

Deleting a cookie is very simple. All you need to do is set the expiration date to some time in the past with the same name, path, domain, and secure option:

You can also use the setCookie() function to remove the cookie:

✌️ Like this article? Follow me on Twitter and LinkedIn. You can also subscribe to RSS Feed.

Learn how HTTP Cookies work

Cookies are a fundamental part of the Web, as they allow sessions and in general to recognize the users during the navigation

Published Mar 30 2018

Introduction

By using Cookies we can exchange information between the server and the browser to provide a way to customize a user session, and for servers to recognize the user between requests.

HTTP is stateless, which means all request origins to a server are exactly the same and a server cannot determine if a request comes from a client that already did a request before, or it’s a new one.

Cookies are sent by the browser to the server when an HTTP request starts, and they are sent back from the server, which can edit their content.

Cookies are essentially used to store a session id.

In the past cookies were used to store various types of data, since there was no alternative. But nowadays with the Web Storage API (Local Storage and Session Storage) and IndexedDB, we have much better alternatives.

Cookies have a long history, they had their first version in 1994, and over time they were standardized in multiple RFC revisions.

RFC stands for Request for Comments, the way standards are defined by the Internet Engineering Task Force (IETF), the entity responsible for setting standards for the Internet

The latest specification for Cookies is defined in the RFC 6265, which is dated 2011.

Restrictions of cookies

Cookies can be set or read server side, or client side.

In the client side, cookies are exposed by the document object as document.cookie

Set cookies

The simplest example to set a cookie is:

This will add a new cookie to the existing ones (it does not overwrite existing cookies)

Set a cookie expiration date

If you don’t set anything else, the cookie will expire when the browser is closed. To prevent so, add an expiration date, expressed in the UTC format ( Mon, 26 Mar 2018 17:04:05 UTC )

A simple JavaScript snippet to set a cookie that expires in 24 hours is:

Alternatively you can use the max-age parameter to set an expiration expressed in number of seconds:

Set a cookie path

The path parameter specifies a document location for the cookie, so it’s assigned to a specific path, and sent to the server only if the path matches the current document location, or a parent:

Set a cookie domain

The domain can be used to specify a subdomain for your cookie.

If not set, it defaults to the host portion even if using a subdomain (if on subdomain.mydomain.com, by default it’s set to mydomain.com). Domain cookies are included in subdomains.

Cookie Security

Secure

Adding the Secure parameter makes sure the cookie can only be transmitted securely over HTTPS, and it will not be sent over unencrypted HTTP connections:

HttpOnly

SameSite

Update a cookie value or parameter

To update the value of a cookie, just assign a new value to the cookie name:

Similar to updating the value, to update the expiration date, reassign the value with a new expires or max-age property:

Delete a cookie

To delete a cookie, unset its value and pass a date in the past:

(and again, with all the parameters you used to set it)

Access the cookies values

To access a cookie, lookup document.cookie :

This will return a string with all the cookies set for the page, semicolon separated:

Check if a cookie exists

Abstractions libraries

There are a number of different libraries that will provide a friendlier API to manage cookies. One of them is https://github.com/js-cookie/js-cookie, which supports up to IE7, and has a lot of stars on GitHub (which is always good).

Some examples of its usage:

Use that or the native Cookies API?

It all comes down to adding more kilobytes to download for each user, so it’s your choice.

Use cookies server-side

Every environment used to build an HTTP server allows you to interact with cookies, because cookies are a pillar of the Modern Web, and not much could be built without them.

Let’s do an example with Node.js

When using Express.js, you can create cookies using the res.cookie API:

To parse cookies, a good choice is to use the https://github.com/expressjs/cookie-parser middleware. Every Request object will have cookies information in the req.cookie property:

If you create your cookies using signed: true :

they will be available in the req.signedCookies object instead. Signed cookies are protected against modifications on the client. The signature used to sign a cookie value makes sure that you can know, server-side, if the client has modified it.

https://github.com/expressjs/session and https://github.com/expressjs/cookie-session are two different middleware options to build cookie-based authentication, which one to use depends on your needs.

Inspect cookies with the Browser DevTools

All browsers in their DevTools provide an interface to inspect and edit cookies.

Chrome

Firefox

Safari

Alternatives to cookies

Are cookies the only way to build authentication and sessions on the Web?

No! There is a technology that recently got popular, called JSON Web Tokens (JWT), which is a Token-based Authentication.

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:

We can also access cookies from the browser, using document.cookie property.

There are many tricky things about cookies and their options. In this chapter we’ll cover them in detail.

Reading from document.cookie

Does your browser store any cookies from this site? Let’s see:

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

A write operation to document.cookie updates only cookies mentioned in it, but doesn’t touch other cookies.

For instance, this call sets a cookie with the name user and value John :

Technically, name and value can have any characters. To keep the valid formatting, they should be escaped using a built-in encodeURIComponent function:

There are few limitations:

Cookies have several options, many of them are important and should be set.

The url path prefix must be absolute. It makes the cookie accessible for pages under that path. By default, it’s the current path.

Usually, we should set path to the root: path=/ to make the cookie accessible from all website pages.

domain

A domain defines where the cookie is accessible. In practice though, there are limitations. We can’t set any domain.

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.

For historical reasons, domain=.site.com (with a dot before site.com ) also works the same way, allowing access to the cookie from subdomains. That’s an old notation and should be used if we need to support very old browsers.

To summarize, the domain option allows to make a cookie accessible at subdomains.

expires, max-age

By default, if a cookie doesn’t have one of these options, it disappears when the browser is closed. Such cookies are called “session cookies”

To let cookies survive a browser close, we can set either the expires or max-age option.

The cookie expiration date defines the time, when the browser will automatically delete it.

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.

Is 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

The cookie should be transferred only over HTTPS.

That is, cookies are domain-based, they do not distinguish between the protocols.

samesite

To understand how it works and when it’s useful, let’s take a look at XSRF attacks.

XSRF attack

That’s 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 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.

Enter cookie samesite option

The cookie samesite option provides another way to protect from such attacks, that (in theory) should not require “xsrf protection tokens”.

It has two possible values:

A cookie with samesite=strict is never sent if the user comes from outside the same site.

If authentication cookies have the samesite option, then a XSRF attack has no chances to succeed, because a submission from evil.com comes without cookies. So bank.com will not recognize the user and will not proceed with the payment.

Although, there’s a small inconvenience.

A more relaxed approach that also protects from XSRF and doesn’t break the user experience.

A samesite=lax cookie is sent if both of these conditions are true:

The HTTP method is “safe” (e.g. GET, but not POST).

The full list of safe HTTP methods is in the RFC7231 specification. Basically, 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.

The operation performs a top-level navigation (changes URL in the browser address bar).

So, what samesite=lax does, is to basically allow the most common “go to URL” operation to have cookies. E.g. opening a website link from notes that satisfy these conditions.

But anything more complicated, like a network request from another site or a form submission, loses cookies.

If that’s fine for you, then adding samesite=lax will probably not break the user experience and add protection.

Overall, samesite is a great option.

There’s a drawback:

So if we solely rely on samesite to provide protection, then old browsers will be vulnerable.

But we surely can use samesite together with other protection measures, like xsrf tokens, to add an additional layer of defence and then, in the future, when old browsers die out, we’ll probably be able to drop xsrf tokens.

httpOnly

This option has nothing to do with JavaScript, but we have to mention it for completeness.

The web-server uses the Set-Cookie header to set a cookie. Also, it may set the httpOnly option.

That’s used as a precaution measure, to protect from certain attacks when a hacker injects his own JavaScript code into a page and waits for a user to visit that page. That shouldn’t be possible at all, hackers should not be able to inject their code into our site, but there may be bugs that let them do it.

Normally, if such a thing happens, and a user visits a web-page with hacker’s JavaScript code, then that code executes and gains access to document.cookie with user cookies containing authentication information. That’s bad.

Appendix: Cookie functions

There exist many cookie libraries for that, so these are for demo purposes. Fully working though.

getCookie(name)

The shortest way to access a cookie is to use a regular expression.

The function getCookie(name) returns the cookie with the given name :

Please note that a cookie value is encoded, so getCookie uses a built-in decodeURIComponent function to decode it.

setCookie(name, value, options)

Sets the cookie’s name to the given value with path=/ by default (can be modified to add other defaults):