После получения HTTP-запроса сервер может отправить один или несколько заголовков Set-Cookie в ответе. Браузер обычно сохраняет куки и отправляет его с запросами к тому же серверу в заголовке Cookie HTTP. Можно указать дату или период истечения срока действия, после которого куки не должны отправляться. Также можно установить дополнительные ограничения на определённый домен и путь, чтобы ограничить место, куда отправляется куки. Подробную информацию о заголовках, упомянутых ниже, см. в справочной статье Set-Cookie.

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

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

Это сообщает серверу отправлять заголовки, чтобы сообщить клиенту сохранить пару куки:

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

[page content]

Затем при каждом последующем запросе к серверу браузер отправляет все ранее сохранённые куки обратно на сервер с помощью заголовка Cookie.

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

Срок действия куки можно определить двумя способами:

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

Например:

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

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

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

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

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

Вот пример:

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

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

Атрибут domain

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

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

Атрибут path

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

Например, если вы зададите Path=/docs, этим запрошенным путям соответствуют:

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

Но этим запрошенным путям не соответствуют:

• /
• /docsets
• /fr/docs

Атрибут SameSite

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

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

Вот пример:

Set-Cookie: mykey=myvalue; SameSite=Strict

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

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

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

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

__Host-

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

__Secure-

Если имя файла cookie имеет этот префикс, оно принимается в заголовке Set-Cookie, только если отмечено атрибутом Secure и было отправлено из безопасного источника. Это слабее, чем префикс __Host-.

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

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

Доступ к файлам cookie с помощью JavaScript Document.cookie

Вы можете создавать новые файлы cookie через JavaScript с помощью свойства Document.cookie. Вы также можете получить доступ к существующим файлам cookie из JavaScript, если флаг HttpOnly не установлен.

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

Файлы cookie, созданные через JavaScript, не могут включать флаг HttpOnly.

Обратите внимание на проблемы безопасности в разделе Безопасность ниже. Файлы cookie, доступные JavaScript, могут быть украдены через XSS.

Способы смягчения атак, связанных с файлами cookie:

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

Файл cookie связан с конкретным доменом и схемой (например, http или https), а также может быть связан с поддоменами, если атрибут Domain заголовка Set-Cookie установлен. Если домен и схема файла cookie соответствуют текущей странице, файл cookie считается принадлежащим к тому же сайту, что и страница, и называется файлом cookie первой стороны.

Если домен и схема отличаются, файл cookie не считается принадлежащим к тому же сайту, и называется файлом cookie третьей стороны. Хотя сервер, размещающий веб-страницу, устанавливает файлы cookie первой стороны, страница может содержать изображения или другие компоненты, хранящиеся на серверах других доменов (например, баннеры объявлений), которые могут устанавливать файлы cookie третьих сторон. Они в основном используются для рекламы и отслеживания в сети. Например, типы файлов cookie, используемых Google.

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

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

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

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

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

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

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

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

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

• Set-Cookie
• Cookie
• Document.cookie
• Navigator.cookieEnabled
• Файлы cookie SameSite
• Просмотр файлов cookie с помощью Storage Inspector
• Спецификация файлов cookie: RFC 6265
• Файл cookie HTTP в Википедии
• Файлы cookie, GDPR и Директива о конфиденциальности электронных данных