
Что такое cookies
Сайт сохраняет в браузере посетителя небольшой фрагмент данных: cookie, или куки. HTTP сам по себе не хранит память о клиенте, и каждый запрос приходит отдельно. Через cookie сайт узнаёт, что это тот же человек, который уже входил в аккаунт, держал товар в корзине или выбрал язык.
Сервер отвечает заголовком Set-Cookie, браузер сохраняет значение и при следующих запросах к этому сайту сам возвращает его в заголовке Cookie.
Ответ сайта:
Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax
Позже браузер сам пришлёт:
Cookie: session=abc123
Cookie — это не программа и не вирус, а небольшая запись, которую браузер сохраняет для сайта. Что именно в ней хранится и как она используется, зависит от конкретного сайта и его настроек. .
Зачем cookies нужны сайту
На сайтах cookies обычно закрывают такие задачи:
Сессия и вход: пользователь остаётся авторизованным.
Удобство: язык, тема, содержимое корзины, согласие на cookies.
Аналитика и маркетинг: откуда пришёл трафик и как ведут себя посетители.
Сессия и настройки интерфейса нужны, чтобы сайт работал. Аналитика и маркетинг добавляют устойчивый идентификатор, и визиты можно связать во времени. Отсюда споры про приватность и cookie-баннеры.
Свои и чужие cookies: в чём разница
Браузер смотрит на контекст загрузки.
First-party (свои): cookies сайта из адресной строки. Например, вы на shop.example, и cookie ставит shop.example.
Third-party (чужие, сторонние): cookies другого домена, встроенного в страницу: реклама, аналитика, виджет чата, кнопка соцсети, платёжный iframe.
Один и тот же сервис на своём сайте будет своим, а на вашем чужим. В документации WebKit это сказано прямо: отдельного вида cookie под названием third-party не существует, есть cookie в third-party контексте.

Подключили Метрику, пиксель рекламы, чат или оплату, и на странице уже могут появиться сторонние cookies, даже если свой код их не ставил.
Пример на обычном сайте магазина
Пользователь открывает каталог магазина. Сайт ставит свою session-cookie, это обычная сессия. Параллельно в коде стоят Яндекс.Метрика, рекламный pixel и виджет чата, и каждый может обратиться к своему домену. Если браузер не блокирует сторонние cookies, у посетителя появляются идентификаторы сразу нескольких компаний, хотя в адресной строке один shop.example.
Поэтому на сайтах висят cookie-баннер и список партнёров. Посетителю показывают и ваши cookies, и то, кто ещё получает данные со страницы.
Как работает трекинг через cookies
Классическая схема кросс-сайтового трекинга выглядит так:
Человек заходит на сайт А.
На сайте подключён скрипт или pixel рекламной/аналитической сети.
Сеть записывает в браузер свой ID (если браузер это позволяет).
Тот же скрипт стоит на сайтах Б, В и Г, и сеть узнаёт тот же браузер.
Отсюда эффект, когда кроссовки смотрели на одном сайте, а реклама догоняет на другом. Сеть повторно видит один идентификатор на многих площадках.
Исследование Princeton/OpenWPM (2016) на миллионе сайтов замерило cookie-трекинг, обмен идентификаторами между трекерами и fingerprinting. PETS 2022 отдельно описал восстановление удалённой cookie по отпечатку браузера.
Трекинг бывает и first-party. Если ID пишет ваш домен (аналитика, CRM, атрибуция), браузер считает такую cookie своей. Для пользователя и для закона она может оставаться идентификатором поведения: действия человека связываются во времени.
Какие настройки cookies важны
Secure и HttpOnly
Secure: cookie уходит только по HTTPS. HttpOnly: JavaScript её не видит. Для сессии входа оба флага почти обязательны, иначе cookie проще перехватить по сети или украсть через XSS.
SameSite
SameSite говорит браузеру, можно ли отправлять cookie в запросах с другого сайта.
Lax: обычный выбор по умолчанию. Удобно для входа по ссылке, и cookie не уходит на каждый чужой pixel.
Strict: строже. Подходит для чувствительных сценариев и неудобен, если человек перешёл по ссылке и должен сразу оказаться в аккаунте.
None: cookie можно отправлять в cross-site запросах, но только вместе с Secure. Так работают некоторые виджеты и iframe, и так же раньше ходили сторонние трекеры.

Сессию интернет-магазина не ставьте в SameSite=None «на всякий случай». Если ломается оплата или SSO в iframe, разбирайте этот случай отдельно, не открывая все cookies наружу.
Нормальная сессия сайта
Set-Cookie: sid=…; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=3600Трекинг помимо cookies
Браузер можно узнать и после очистки cookies. На сайтах встречаются и другие механизмы:
localStorage и IndexedDB: хранилища в браузере, куда тоже можно записать ID.
Пиксели и цепочки редиректов: даже пустая картинка 1×1 делает HTTP-запрос.
Fingerprinting: сбор характеристик браузера и устройства (экран, шрифты, canvas и т.п.) без обязательной записи cookie.
Фраза «мы не используем cookies» пропускает другие идентификаторы и скрипты на странице. Браузеры ограничивают и cookies, и стороннее хранилище.
Как браузеры ограничивают трекинг

Safari (ITP) по умолчанию блокирует сторонние cookies. Поэтому iframe-логины и виджеты часто ломаются именно в Safari.
Firefox в обычном режиме разделяет сторонние cookies по сайтам (Total Cookie Protection). В строгом режиме блокирует их жёстче.
Chrome долго планировал полное отключение third-party cookies, но в 2024-2025 оставил выбор за пользователем в настройках. В режиме Incognito сторонние cookies уже блокируются.
Проверяйте интеграции минимум в Safari и в Firefox со строгой защитой. Сценарий, который живёт только в Chrome с настройками по умолчанию, легко ломается в других браузерах.
Для виджетов есть более мягкий вариант, Partitioned cookies (CHIPS). Сторонний сервис может помнить состояние внутри вашего сайта и не склеивать пользователя между разными сайтами одним ID. Если нужен state во iframe, это обычно лучше старого общего third-party cookie.
Что важно проверить
Разделите cookies на нужные для работы сайта и маркетинговые. Вторые подключайте после согласия в баннере.
Проверьте, что баннер не врёт: если человек нажал «отклонить», аналитические ID не должны записываться.
Сессионные cookies: Secure + HttpOnly + SameSite=Lax (или Strict, если UX позволяет).
Составьте список всех тегов: Метрика, реклама, чат, CRM, pixel. Для каждого запишите домен и cookies.
Прогоните вход, оплату, чат и виджеты в Safari и Firefox Strict.
Не дублируйте один и тот же ID сразу в cookie, localStorage и URL. После очистки такой ID проще восстановить.
Аналитику иногда грузят через свой поддомен (proxy). Для браузера запросы становятся своими, и измерение держится стабильнее. Ответственность за данные остаётся на владельце сайта: идентификация посетителя сохраняется, просто запросы идут через ваш домен.
Короткий чеклист аудита
Перед релизом или подключением нового тега:
1. Открыть DevTools → Application → Cookies на чистом профиле.
2. Выписать все cookies: свои / чужие, срок жизни, Secure, HttpOnly, SameSite.
3. Проверить сессию входа: есть Secure и HttpOnly, нет лишнего SameSite=None.
4. Сравнить набор cookies до и после «Принять» / «Отклонить» в баннере.
5. Посмотреть Network: какие сторонние скрипты и pixels грузятся сразу.
6. Повторить вход/оплату/чат в Safari и Firefox Strict.
7. Зафиксировать владельца каждого тега (кто подключил и зачем).
Глоссарий
First-party cookie: cookie сайта, который открыт в адресной строке.
Third-party cookie: cookie другого домена, встроенного в страницу.
Pixel: маленький запрос (часто картинка 1×1) для фиксации события или ID.
Fingerprinting: узнавание браузера по набору технических признаков.
CMP: платформа согласий, cookie-баннер.
SameSite: правило, когда cookie можно отправлять в cross-site запросах.
ITP / ETP: защита от трекинга в Safari и Firefox.
Вывод
Cookies запоминают посетителя на сайте. Когда один сторонний сервис стоит на многих площадках, тот же механизм связывает визиты между ними. Safari, Firefox и настройки Chrome ограничивают чужие cookies, поэтому сессию настраивают отдельно от аналитики и виджетов, а сценарии проверяют и вне Chrome.
Сначала выпишите, какие идентификаторы пишет сайт. Потом уже разбирайте баннер, метрики и фразу «мы ничего не трекаем».

Интересует похожий проект?
Всё очень просто!


