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

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

Для чего используются файлы cookie

Как правило, сервер использует содержимое файлов cookie HTTP, чтобы определить, поступают ли разные запросы от одного и того же браузера/пользователя, а затем отправляет персонализированный или обычный ответ в зависимости от ситуации. Ниже описана базовая система входа пользователя:

1. Пользователь отправляет серверу учетные данные для входа, например, отправляя форму.
2. Если учетные данные верны, сервер обновляет интерфейс, чтобы показать, что пользователь вошел в систему, и отправляет файл cookie с идентификатором сеанса, который фиксирует статус входа в браузере.
3. Позже пользователь переходит на другую страницу того же сайта. Браузер отправляет файл cookie с идентификатором сеанса вместе с соответствующим запросом, чтобы показать, что он по-прежнему считает пользователя вошедшим в систему.
4. Сервер проверяет идентификатор сеанса и, если он все еще действителен, отправляет пользователю персонализированную версию новой страницы. Если идентификатор недействителен, он удаляется, а пользователю показывается обычная версия страницы (или, возможно, сообщение «доступ запрещен» с просьбой войти снова).

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

• Управление сеансом: статус входа пользователя, содержимое корзины покупок, игровые результаты или любые другие сведения о сеансе пользователя, которые серверу необходимо запомнить.
• Персонализация: пользовательские настройки, например язык отображения и тема интерфейса.
• Отслеживание: запись и анализ поведения пользователей.

Хранение данных

На заре развития веба, когда других вариантов не было, файлы cookie использовались для хранения данных на стороне клиента. Сейчас рекомендуется использовать современные API хранилищ, например Web Storage API (localStorage и sessionStorage) и IndexedDB.

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

• Браузеры обычно ограничивают количество файлов cookie для одного домена (в зависимости от браузера, как правило, их несколько сотен) и максимальный размер каждого файла cookie (обычно 4 КБ). API хранилищ позволяют хранить больше данных.
• Файлы cookie отправляются с каждым запросом, поэтому они могут снижать производительность (например, при медленном мобильном подключении), особенно если их установлено много.

Создание, удаление и обновление файлов cookie

Получив HTTP-запрос, сервер может отправить в ответе один или несколько заголовков Set-Cookie, каждый из которых установит отдельный файл cookie. Файл cookie устанавливается с помощью пары «имя — значение», например:

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

Следующий ответ HTTP указывает принимающему браузеру сохранить пару файлов cookie:

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

[page content]

При отправке нового запроса браузер обычно отправляет серверу ранее сохраненные файлы cookie для текущего домена в заголовке HTTP Cookie:

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

Удаление: определение срока действия файла cookie

Можно указать дату истечения срока действия или период времени, по истечении которого файл cookie следует удалить и больше не отправлять. В зависимости от атрибутов, заданных в заголовке Set-Cookie при создании файлов cookie, они могут быть постоянными или сеансовыми:

• Постоянные файлы cookie удаляются после даты, указанной в атрибуте Expires:

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

  или по истечении периода, указанного в атрибуте Max-Age:

  Set-Cookie: id=a3fWa; Max-Age=2592000
  

  Примечание: Expires существует дольше, чем Max-Age, однако Max-Age менее подвержен ошибкам и имеет приоритет, если заданы оба атрибута. Это объясняется тем, что при задании даты и времени Expires они отсчитываются относительно клиента, на котором устанавливается файл cookie. Если время на сервере отличается, это может привести к ошибкам.

• Сеансовые файлы cookie — файлы cookie без атрибута Max-Age или Expires — удаляются по завершении текущего сеанса. Браузер определяет, когда заканчивается «текущий сеанс», а некоторые браузеры при перезапуске используют восстановление сеанса. В результате сеансовые файлы cookie могут храниться бесконечно.

  Примечание: Если ваш сайт выполняет аутентификацию пользователей, при каждой аутентификации следует создавать и повторно отправлять сеансовые файлы cookie, даже если они уже существуют. Такой подход помогает предотвратить атаки типа фиксация сеанса, при которых третья сторона может повторно использовать сеанс пользователя.

Чтобы немедленно удалить файл cookie, установите его повторно с теми же именем, путем и доменом (если они указаны), а для атрибута Expires задайте дату в прошлом или для атрибута Max-Age задайте значение 0 либо отрицательное значение. Это указывает браузеру сразу же удалить файл cookie. Например:

Set-Cookie: id=a3fWa; Max-Age=0

Также можно удалить все файлы cookie, связанные с регистрируемым доменом, с помощью заголовка ответа Clear-Site-Data. Например, следующий заголовок, отправленный с https://foo.example.com/, удалит все файлы cookie, отправленные example.com и всеми его поддоменами, например all.bar.example.com.

Clear-Site-Data: "cookies"

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

Обновление значений файлов cookie

Чтобы обновить файл cookie через HTTP, сервер может отправить заголовок Set-Cookie с именем существующего файла cookie и новым значением. Например:

Set-Cookie: id=new-value

Это может потребоваться по нескольким причинам. Например, пользователь изменил свои настройки, и приложение хочет отразить изменения в данных на стороне клиента (это также можно сделать с помощью механизма клиентского хранилища, например Web Storage).

Обновление файлов cookie с помощью JavaScript

В браузере можно создавать файлы cookie с помощью JavaScript, используя свойство Document.cookie или асинхронный Cookie Store API. Обратите внимание, что во всех приведенных ниже примерах используется Document.cookie, поскольку этот вариант поддерживается шире остальных и является наиболее устоявшимся.

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

Также можно получить доступ к существующим файлам cookie и задать для них новые значения:

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"

В целях безопасности нельзя изменять значения файлов cookie, напрямую отправляя обновленный заголовок Cookie при создании запроса, например с помощью fetch() или XMLHttpRequest.

Есть веские причины не разрешать JavaScript изменять файлы cookie вообще. Чтобы запретить JavaScript доступ к файлу cookie, при его создании укажите атрибут HttpOnly. Подробнее см. в разделе «Безопасность».

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

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

Защитить файлы cookie можно разными способами, которые рассмотрены в этом разделе.

Блокировка доступа к файлам cookie

Можно обеспечить безопасную отправку файлов cookie и защитить их от доступа нежелательных пользователей или скриптов одним из двух способов: с помощью атрибута Secure и атрибута HttpOnly:

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

• Файл cookie с атрибутом Secure отправляется серверу только в зашифрованном запросе по протоколу HTTPS. Он никогда не отправляется по незащищенному HTTP (за исключением localhost), что затрудняет доступ к нему для злоумышленников, проводящих атаки типа «человек посередине». Небезопасные сайты (с http: в URL) не могут устанавливать файлы cookie с атрибутом Secure. Однако не следует считать, что Secure полностью защищает конфиденциальную информацию в файлах cookie. Например, человек с доступом к жесткому диску клиента (или к JavaScript, если атрибут HttpOnly не задан) может прочитать и изменить эту информацию.

• Файл cookie с атрибутом HttpOnly недоступен для JavaScript, например через Document.cookie; к нему можно получить доступ только после отправки на сервер. Например, файлы cookie, сохраняющие сеансы пользователей, должны иметь атрибут HttpOnly — предоставлять к ним доступ JavaScript было бы крайне небезопасно. Эта мера предосторожности помогает снизить риск атак межсайтового скриптинга (XSS).

Определение адресатов файлов cookie

Атрибуты Domain и Path определяют область действия файла cookie: URL-адреса, которым он отправляется.

• Атрибут Domain указывает, какой сервер может получить файл cookie. Если он задан, файл cookie доступен указанному серверу и его поддоменам. Например, если задать Domain=mozilla.org для mozilla.org, файлы cookie будут доступны на этом домене и его поддоменах, например developer.mozilla.org.

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

  Если в заголовке Set-Cookie не указан атрибут Domain, файлы cookie доступны серверу, который их устанавливает, но не его поддоменам. Поэтому указание Domain менее ограничительно, чем его отсутствие. Обратите внимание, что сервер может задать атрибут Domain только для собственного домена или родительского домена, но не для поддомена или другого домена. Например, сервер с доменом foo.example.com может задать атрибуту значение example.com или foo.example.com, но не bar.foo.example.com или elsewhere.com (при этом файлы cookie по-прежнему будут отправляться поддоменам, например bar.foo.example.com). Подробнее см. в разделе «Недопустимые домены».

• Атрибут Path указывает путь URL, который должен присутствовать в запрашиваемом URL, чтобы отправить заголовок Cookie. Например:

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

  Символ %x2F ("/") считается разделителем каталогов, поэтому совпадения распространяются и на подкаталоги. Например, если задать Path=/docs, этим условием будут соответствовать следующие пути запросов:

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

  А следующие пути запросов ему не соответствуют:

  • /
  • /docsets
  • /fr/docs

  Примечание: Атрибут path позволяет управлять тем, какие файлы cookie браузер отправляет в зависимости от разных частей сайта. Он не предназначен для защиты и не защищает от несанкционированного чтения файла cookie по другому пути.

Управление сторонними файлами cookie с помощью SameSite

Атрибут SameSite позволяет серверам указывать, отправлять ли файлы cookie и когда отправлять их с межсайтовыми запросами, то есть со сторонними файлами cookie. Межсайтовые запросы — это запросы, в которых сайт (регистрируемый домен) и/или схема (http или https) отличаются от сайта, который пользователь посещает в данный момент. К таким запросам относятся запросы, отправляемые при переходе на ваш сайт по ссылкам с других сайтов, а также любые запросы от встроенного стороннего содержимого.

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

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

  Set-Cookie: cart=110045_77895_53420; SameSite=Strict
  

  Примечание: Для файлов cookie, содержащих конфиденциальную информацию, также следует установить небольшой срок действия.

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

  Set-Cookie: affiliate=e4rt45dw; SameSite=Lax
  

• None указывает отправлять файлы cookie как с исходными, так и с межсайтовыми запросами. Это полезно, если нужно отправлять файлы cookie вместе с запросами от стороннего содержимого, встроенного на другие сайты, например от рекламных или аналитических сервисов. Обратите внимание: если задано SameSite=None, необходимо также задать атрибут Secure — для SameSite=None требуется безопасный контекст.

  Set-Cookie: widget_session=7yjgj57e4n3d; SameSite=None; Secure; HttpOnly
  

Если атрибут SameSite не задан, по умолчанию файл cookie считается Lax.

Префиксы файлов cookie

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

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

В качестве дополнительной меры защиты можно использовать префиксы файлов cookie, чтобы налагать определенные ограничения на атрибуты файлов cookie в поддерживающих их пользовательских агентах. Все префиксы файлов cookie начинаются с двух символов подчеркивания (__) и заканчиваются дефисом (-). Доступны четыре префикса:

• __Secure-: Файлы cookie, имена которых начинаются с __Secure-, должны устанавливаться защищенной страницей (HTTPS) с атрибутом Secure.
• __Host-: Файлы cookie, имена которых начинаются с __Host-, должны устанавливаться защищенной страницей (HTTPS) с атрибутом Secure. Кроме того, для них нельзя задавать атрибут Domain, а атрибут Path должен иметь значение /. Это гарантирует, что такие файлы cookie отправляются только установившему их узлу, а не другим узлам домена. Также это гарантирует, что они устанавливаются для всего узла и не могут быть переопределены ни по одному из путей этого узла. Благодаря такому сочетанию атрибутов файл cookie максимально приближен к случаю, когда источник считается границей безопасности.
• __Http-: Файлы cookie, имена которых начинаются с __Http-, должны устанавливаться защищенной страницей (HTTPS) с флагом Secure. Кроме того, у них должен быть задан атрибут HttpOnly, подтверждающий, что они установлены через заголовок Set-Cookie (их нельзя установить или изменить с помощью возможностей JavaScript, таких как Document.cookie или Cookie Store API).
• __Host-Http-: Файлы cookie, имена которых начинаются с __Host-Http-, должны устанавливаться защищенной страницей (HTTPS) с флагом Secure и иметь атрибут HttpOnly, подтверждающий, что они установлены через заголовок Set-Cookie. Кроме того, для них действуют те же ограничения, что и для файлов cookie с префиксом __Host-. Такое сочетание атрибутов максимально приближает файл cookie к случаю, когда источник считается границей безопасности, и одновременно гарантирует, что разработчики и операторы серверов знают об ограничении его области действия HTTP-запросами.

Браузер отклонит файлы cookie с этими префиксами, если они не соответствуют указанным ограничениям. Поскольку сервер приложения проверяет только конкретное имя файла cookie при определении того, прошел ли пользователь аутентификацию или верен ли токен CSRF, это фактически служит защитой от атак типа фиксация сеанса.

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

Конфиденциальность и отслеживание

Ранее мы говорили о том, как атрибут SameSite можно использовать для управления отправкой сторонних файлов cookie и как это помогает защищать конфиденциальность пользователей. Конфиденциальность очень важна при создании сайтов: грамотный подход помогает завоевать доверие пользователей. Непродуманный подход может полностью подорвать это доверие и вызвать множество других проблем.

Сторонние файлы cookie могут устанавливаться сторонним содержимым, встроенным на сайты с помощью элементов <iframe>. У них есть множество законных способов применения, включая обмен сведениями о профилях пользователей, подсчет показов рекламы и сбор аналитических данных на разных связанных доменах.

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

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

Подробные сведения о сторонних файлах cookie, связанных с ними проблемах и доступных альтернативах приведены в нашей статье «Сторонние файлы cookie». Общие сведения о конфиденциальности см. на нашей странице о конфиденциальности.

Нормативные требования к файлам cookie

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

• Общий регламент по защите данных (GDPR) в Европейском союзе
• Директива ЕС об электронной конфиденциальности
• Закон Калифорнии о защите конфиденциальности потребителей

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

Эти нормативные требования включают, например, следующие положения:

• Уведомлять пользователей об использовании файлов cookie на сайте.
• Позволять пользователям отказаться от получения некоторых или всех файлов cookie.
• Позволять пользователям пользоваться большей частью сервиса без получения файлов cookie.

В вашем регионе могут действовать и другие нормативные требования, регулирующие использование файлов cookie. Вы обязаны знать эти требования и соблюдать их. Некоторые компании предлагают код для «баннеров файлов cookie», который помогает соответствовать таким требованиям.

См. также

• Связанные заголовки HTTP: Set-Cookie, Cookie
• Связанные API JavaScript: Document.cookie, Navigator.cookieEnabled, Cookie Store API
• Сторонние файлы cookie
• Спецификация файлов cookie: RFC 6265
• Файлы cookie, GDPR и Директива об электронной конфиденциальности