SameSite (cookie)

Определение

SameSite – атрибут заголовка Set-Cookie, определяющий, отправит ли браузер cookie в межсайтовом запросе. Значения: Strict, Lax и None; без атрибута Chrome с версии 80 (февраль 2020) применяет Lax по умолчанию.

4 мин 82 21 июля 2026 Обновлено 12 августа

SameSite появился как расширение спецификации cookie в 2016 году и решает конкретную проблему: исторически браузер отправлял cookie при каждом запросе к её домену – в том числе когда запрос уходил со стороннего сайта через картинку, скрипт или iframe. Этим пользовались и CSRF-атаки, и межсайтовый трекинг. Атрибут в заголовке Set-Cookie позволяет серверу явно указать, в каких межсайтовых сценариях браузеру можно передавать cookie, а в каких – нет. SameSite – механизм чисто технический; юридическая сторона использования cookie – персональные данные, политика конфиденциальности и 152-ФЗ – разобрана в отдельных терминах глоссария.

Как это работает

Сервер задаёт атрибут при установке cookie: Set-Cookie: sessionid=38afes7a8; SameSite=Lax. Дальше при каждом запросе браузер сравнивает сайт, открытый в адресной строке, с сайтом, которому принадлежит cookie, и по значению атрибута решает, отправлять её или нет.

Значение	Когда cookie отправляется	Типовой сценарий
Strict	Только в same-site запросах. Даже при переходе по внешней ссылке cookie в первом запросе не уйдёт	Анти-CSRF-токены, админские и банковские сессии
Lax	Same-site запросы плюс межсайтовая навигация верхнего уровня безопасным методом (GET/HEAD/OPTIONS). Не отправляется из `fetch()`, `<img>`, `<script>`, iframe и POST-форм с чужого сайта	Сессионные cookie большинства сайтов; значение по умолчанию
None	Во всех контекстах, включая межсайтовые, – но только вместе с атрибутом `Secure` (HTTPS). Без Secure браузер отклонит cookie	Встраиваемые виджеты, iframe, SSO, аналитические и рекламные пиксели

Если атрибут не указан, современные браузеры трактуют cookie как SameSite=Lax – Chrome перешёл на этот дефолт с версии 80 в феврале 2020 года, тогда же None без Secure стал отклоняться.

У дефолтного Lax есть смягчение – «двухминутное» исключение: cookie, установленная не более двух минут назад, всё же отправится в межсайтовом POST-запросе верхнего уровня. Оно придумано ради платёжных редиректов вроде 3-D Secure и SSO-сценариев, где внешний сервис возвращает пользователя на сайт POST-формой. Важно: окно действует только для cookie без атрибута; явно заданный SameSite=Lax блокирует такую отправку всегда.

Same-site и same-origin – в чём разница

SameSite сравнивает не origin, а site. По определению MDN site – это схема плюс регистрируемый домен (eTLD+1); порт не учитывается. Origin строже: схема, полный хост и порт целиком.

Случай	Пример	Same-origin	Same-site
Поддомены	`www.example.com` и `static.example.com`	Нет	Да – один eTLD+1
Схема	`http://` и `https://` одного домена	Нет	Нет – схема входит в определение site
Порт	`example.com` и `example.com:8443`	Нет	Да – порт не учитывается
Public Suffix List	`a.github.io` и `b.github.io`	Нет	Нет – github.io в списке публичных суффиксов

Зачем это нужно

Главная задача SameSite – защита от CSRF, подделки межсайтовых запросов. Классическая атака: жертва залогинена на сайте, злоумышленник заманивает её на свою страницу, и та отправляет скрытую POST-форму на уязвимый сайт – раньше браузер прикладывал к такому запросу cookie жертвы, и действие выполнялось от её имени. Lax отсекает этот основной вектор, Strict дополнительно закрывает переходы по ссылкам. При этом SameSite – дополнительный барьер, а не замена CSRF-токенам: он не спасает от атак с того же сайта, от GET-эндпоинтов с побочными эффектами и от двухминутного окна.

На практике с атрибутом сталкиваются не только при защите форм:

Авторизация в iframe – личный кабинет или виджет, встроенный на чужой сайт, «разлогинивается»: cookie со Strict или Lax во вложенный межсайтовый iframe не отправляются, и сервер не видит сессию. Нужен SameSite=None; Secure.
Счётчики и пиксели – Метрика, рекламные пиксели и инструменты сквозной аналитики работают в стороннем контексте, поэтому их межсайтовым cookie требуется None. Разметка ссылок UTM-метками от cookie не зависит и потому остаётся самым живучим способом передать источник перехода.
Платежи и SSO – возврат POST-запросом с внешнего сервиса не донесёт явную Lax-cookie: сессию для таких редиректов выносят в отдельную cookie с None; Secure.

Для встраиваемого контента в 2026 голый None – уже не лучшая практика. Рекомендация – добавлять атрибут Partitioned (технология CHIPS): такая cookie получает двойной ключ «домен-установщик + сайт верхнего уровня», виджет хранит состояние на каждом сайте-хозяине отдельно, а межсайтовый трекинг через неё невозможен. С декабря 2025 CHIPS входит в Baseline и работает во всех современных браузерах.

Пример

Четыре типовых заголовка (синтаксис сверен с документацией MDN и web.dev):

Set-Cookie: sessionid=38afes7a8; SameSite=Strict
Set-Cookie: sessionid=38afes7a8; SameSite=Lax
Set-Cookie: widget_session=abc123; SameSite=None; Secure
Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;

Первая строка – анти-CSRF-токен или админская сессия, вторая – обычная пользовательская сессия, третья – cookie встраиваемого виджета, четвёртая – современный вариант той же виджетной cookie: CHIPS с рекомендованным префиксом __Host-. В PHP начиная с версии 7.3 атрибут задаётся через массив опций:

setcookie('name', 'value', ['samesite' => 'Lax', 'secure' => true]);

Рядом с SameSite постоянно всплывает вопрос о судьбе сторонних cookie – и в русскоязычных материалах чаще всего висит застрявшая в 2019 году картина «Chrome вот-вот всё отключит». Актуальный статус на 2026 другой. Chrome сторонние cookie не отключил: в апреле 2025 Google отказался от идеи отдельного запроса на выбор, а 17 октября 2025 в блоге Privacy Sandbox официально подтвердил, что Chrome сохраняет текущий подход – сторонние cookie включены по умолчанию, отключить их можно в настройках. Одновременно Google свернул десять технологий Privacy Sandbox (Topics, Protected Audience, Attribution Reporting API и другие); в развитии остались CHIPS, FedCM и Private State Tokens. Safari при этом полностью блокирует сторонние cookie ещё с 2020 года, а Firefox по умолчанию их партиционирует через Total Cookie Protection. По оценкам consent-платформ, на браузеры без «обычных» сторонних cookie приходится порядка 17–20% трафика – цифра оценочная, но порядок величины ясен: виджеты и трекинг нужно проектировать с расчётом на None плюс Partitioned, не полагаясь на сторонние cookie как на данность.

Частые вопросы

Что будет, если вообще не указать атрибут SameSite?

Современные браузеры, начиная с Chrome 80 (февраль 2020), трактуют такую cookie как SameSite=Lax. При этом действует смягчение: cookie моложе двух минут ещё отправляется в межсайтовом POST-запросе верхнего уровня. Полагаться на дефолт не стоит – явно заданное значение ведёт себя предсказуемее в разных браузерах.

Чем SameSite=Lax отличается от Strict и что ставить для сессии?

Lax отправляет cookie при переходе на сайт по внешней ссылке (top-level навигация методом GET), Strict – нет: после клика по ссылке из письма или мессенджера пользователь выглядит разлогиненным. Поэтому типовая схема – сессионная cookie с Lax, а анти-CSRF-токен или админская сессия – со Strict.

Почему SameSite=None не работает без HTTPS?

По спецификации None обязан сопровождаться атрибутом Secure, а Secure-cookie передаются только по HTTPS. Cookie с SameSite=None без Secure браузер отклонит ещё на этапе установки. Это защита от перехвата: cookie, доступная в любом межсайтовом контексте, по открытому HTTP была бы лёгкой добычей.

Почему в iframe слетает авторизация?

Встроенный на чужой сайт iframe – межсайтовый контекст, и cookie со Strict или Lax браузер туда не отправляет: сервер не видит сессию и считает пользователя гостем. Решение – выдавать такой cookie с SameSite=None; Secure, а лучше добавить Partitioned (CHIPS): Safari и Firefox сторонние cookie блокируют или партиционируют, и голый None там не поможет.

Почему ломается оплата через 3-D Secure или вход по SSO с возвратом POST-запросом?

Возврат с платёжного шлюза или провайдера SSO – это межсайтовый POST, и явно заданная Lax-cookie с ним не отправится: сайт «забывает» пользователя посреди оплаты. Chrome даёт двухминутное окно, но только для cookie без атрибута. Решения: для участвующей в редиректе cookie ставить None; Secure либо переводить возврат на GET-редирект.

SameSite заменяет CSRF-токены?

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

Chrome отключил сторонние cookie или нет?

Нет. В апреле 2025 Google отказался от отдельного запроса выбора, а 17 октября 2025 официально подтвердил в блоге Privacy Sandbox, что Chrome сохраняет текущий подход: сторонние cookie включены по умолчанию, пользователь может отключить их в настройках. При этом Safari блокирует их полностью с 2020 года, а Firefox партиционирует через Total Cookie Protection, так что рассчитывать на сторонние cookie во всех браузерах всё равно нельзя.

Связанные термины

152-ФЗ 152-ФЗ «О персональных данных» – федеральный закон от 27.07.2006, регулирующий сбор, хранение и обработку данных физлиц в России. С 30.05.2025 штрафы за утечки – до 15 млн рублей, за повторные – оборотные, до 3% выручки. UTM-метки UTM-метки – параметры в URL (utm_source, utm_medium, utm_campaign и др.), передающие в Яндекс Метрику и GA4 источник перехода: рекламную систему, кампанию, объявление. Стандарт включает 5 параметров, 3 из них обязательны. Персональные данные (ПДн) Персональные данные (ПДн) – любая информация, относящаяся к прямо или косвенно определённому или определяемому физлицу (п. 1 ст. 3 152-ФЗ). По позиции Роскомнадзора к ПДн относятся и cookie с IP-адресом посетителей сайта. Политика обработки персональных данных Политика обработки персональных данных – обязательный по 152-ФЗ документ оператора: цели, правовые основания, состав и порядок обработки ПДн. При сборе данных через сайт публикуется на его страницах (ч. 2 ст. 18.1 152-ФЗ). сквозная аналитика Система интеграций между рекламными кабинетами, веб-аналитикой, коллтрекингом, CRM и платёжной системой, позволяющая отслеживать путь клиента от первого касания с рекламой до факта оплаты. Даёт реальный ROI каналов на основе выручки.

Материалы по теме

Что почитать дальше по этой теме

Статья Что боты находят на сайте, а вы – нет Боты ходят по изнанке сайта, куда живой человек не забредёт, и фиксируют в логах то, чего не видно ни в Метрике, ни на витрине: падающие с ошибкой 500 страницы каталога, битый файл с 747 обращениями, поток сканеров секретов. Разбираю на реальных логах, что искать и как чинить. 7 мин 216 22 июля 2026 Инструкция Как выгрузить и читать access-логи, если хостинг хранит их три дня Access-лог – единственное место, где виден весь трафик сайта, включая ИИ-ботов, которых не замечают счётчики. Разбираю на практике: где взять логи, как не потерять их из-за ротации, какие команды показывают ботов, ошибки и подозрительную активность. 7 мин 170 21 июля 2026 Флагманский гайд AI-анализ email-обращений: методика на стыке Яндекс.Метрики и Claude Code Классический email-трекинг отвечает на вопрос «откуда пришло обращение». AI-слой отвечает на вопросы, которые раньше требовали ручного аналитика: значим ли email на фоне звонков, форм и мессенджеров, почему один источник даёт качественные обращения, а другой – пустые, какие сегменты визитов предшествуют письму, что написать в ответ с учётом пути пользователя. Здесь – как я собираю это на уже имеющемся стеке: Logs API Метрики, PostgreSQL и Claude Code, без новых платных сервисов. 11 мин 297 26 мая 2026 Флагманский гайд Майкор: ИИ-аудит проекта по 4 точкам контакта Майкор – это перекрёстный ИИ-аудит проекта в 4 точках контакта: сайт, контекстная реклама, AI-поиск и Яндекс.Карты. Я анализирую каждую систему и смотрю связки между ними – где маркетинг рассказывает одно, реклама ведёт на другое, а AI-системы цитируют третий номер телефона. В одном из моих аудитов медицинской клиники в Москве у организации в индексе AI-сервисов оказалось 6 разных номеров и всего 7 упоминаний на 64 проверочных запроса – при том, что в обычной выдаче Яндекса клиника была в топ-1. Майкор закрывает такие разрывы за один аудит вместо четырёх раздельных. 16 мин 501 13 мая 2026 Гайд FAQPage Schema: как разметить блок частых вопросов и попасть в AI-ответы FAQPage schema – один из самых эффективных типов разметки для попадания в AI-ответы. Страницы с FAQPage schema цитируются AI-поисковиками в 2,7 раза чаще. В этом гайде – формат разметки, правила написания ответов для AI, реализация на 1С-Битрикс и типичные ошибки, которые обнуляют эффект. 8 мин 331 25 апреля 2026