Cookie-баннер по закону: как сделать правильно и не получить штраф

Зачем нужен cookie-баннер по закону РФ

Cookie — это маленький текстовый файл, который сайт сохраняет в браузере посетителя. Сам по себе он безобиден: туда часто пишут идентификатор сессии, чтобы пользователь оставался залогиненным. Проблема начинается, когда в cookie попадает уникальный идентификатор посетителя, по которому можно отслеживать его поведение на сайте и между сайтами. С точки зрения 152-ФЗ это уже персональные данные — и значит, для их сбора нужно согласие.

Позиция Роскомнадзора в 2026 году одинаковая: cookie_id, который позволяет идентифицировать конкретного пользователя прямо или косвенно, считается ПД. То же касается fingerprint (отпечатка браузера), Local Storage с уникальными идентификаторами, поведенческих счётчиков и пикселей. Не важно, как технически реализован сбор — важно, что результат позволяет построить профиль человека.

Изменения 266-ФЗ от 2024 года и последующие разъяснения РКН закрыли последнюю серую зону. Раньше можно было спорить, является ли cookie_id персональными данными. Сейчас спор закрыт: ПД, со всеми вытекающими — нужно информирование, нужно активное согласие, нужна возможность отозвать. Без этого — ст. 13.11 КоАП с штрафом от 300 тыс. ₽ для юр. лиц.

На практике под cookie-баннер попадают практически все сайты. Если у вас стоит хотя бы Яндекс.Метрика с Webvisor, есть пиксель ВК для рекламы, чат-виджет Jivo или просто сторонний шрифт с Google Fonts — вы уже собираете cookie третьих сторон. Без баннера это нарушение.

История регулирования cookie в России

До 2017 года про cookie в нашем законе не было сказано ничего конкретного. Сайты ставили счётчики, аналитику, ремаркетинг — никто не задавал вопросов. Первый звонок прозвучал в 2017 году, когда РКН выпустил информационное письмо о том, что cookie_id может относиться к ПД. Это никого особо не напугало — в письме не было обязательных требований, только разъяснение позиции.

Перелом случился в 2018-м, когда в Европе заработал GDPR. Российские сайты, у которых были европейские посетители, начали ставить GDPR-баннеры. По остаточному принципу баннеры стали появляться и на чисто российских проектах — копировали у западных коллег. На этом этапе родился «худший в мире» баннер: огромная зелёная кнопка «Принять всё», крошечная серая ссылка «Настройки», и pre-checked галочки внутри.

В 2021 году вышли первые штрафы — в основном за отсутствие политики конфиденциальности в целом, cookie там были частью претензий. Суммы тогда были смешные (5–15 тыс. ₽), и многие компании платили и забывали. Серьёзный поворот произошёл в сентябре 2022, когда РКН официально включил cookie_id в перечень ПД, требующих согласия, в своих методических рекомендациях.

266-ФЗ от 14 июля 2024 года ужесточил всё разом. Появилось понятие «обработка ПД с согласия в электронной форме», и cookie-баннер стал технически признанной формой такого согласия. Одновременно появились жёсткие требования к содержанию баннера и к запрету dark patterns. С 30 мая 2025 года выросли штрафы — и cookie-нарушения попали в число тех, за которые реально штрафуют.

К 2026 году тренд понятен: РКН переходит от информирования к санкциям, Главрадиочастотный центр запускает автосканы сайтов, и баннеры с pre-checked галочками отлавливаются ботом. Времени «подумать» больше нет — либо вы соответствуете, либо платите.

Что должно быть в правильном баннере

Я свёл всё в семь обязательных элементов. Если хотя бы одного нет, баннер считается ненадлежащим — а значит, согласия как бы не было, и обработка cookie без правового основания.

1. Информирование до сбора

Текст в баннере должен появиться до того, как вы поставили хоть один трекинговый cookie. На практике это значит: на первом экране при заходе пользователя срабатывает только техническая обвязка сайта (HTML, CSS, JS вашего домена). Никакой Метрики, никаких пикселей, никаких сторонних шрифтов с трекингом. Скрипты подключаются только после нажатия «Принять» или «Настроить → Аналитика».

Самая частая ошибка — Метрика лежит в `` и стартует на DOMContentLoaded, а баннер показывается через 200 мс. По факту счётчик уже отправил визит до согласия. Это и есть «обработка без согласия» по ч. 1 ст. 13.11.

2. Активное согласие

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

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

3. Категории cookie с раздельным согласием

Пользователь должен иметь возможность согласиться с одними категориями и отказаться от других. Минимум три категории:

• Необходимые — без них сайт не работает (сессия, корзина, CSRF-токен). Согласия не требуют, но их нужно описать в политике.
• Аналитика — Метрика, поведенческие cookie. Опционально.
• Маркетинг — рекламные пиксели, ремаркетинг. Опционально.

4. Ссылка на политику

В тексте баннера должна быть ссылка на полную политику обработки cookie (или раздел общей политики конфиденциальности). Не «здесь», не «подробнее» — конкретно «Политика в отношении cookie» или подобное. Открываться должна в новой вкладке (`target="_blank"`), чтобы не сбивать пользователя с принятия решения.

5. Кнопка отказа, равная по видимости

Самое больное место. По букве 266-ФЗ и разъяснениям РКН, кнопка «Отказаться» должна быть равной по визуальной значимости кнопке «Принять». Не серая ссылка мелким шрифтом в углу, а кнопка такого же размера, шрифта и контраста. Допустимо отличие в цвете (например, акцентная заливка для «Принять», обводка для «Отказаться»), но не в видимости.

6. Запись согласия с метаданными

Согласие — это не только пользовательский опыт, но и юридический факт. Вы обязаны сохранить:

• дату и время согласия (ISO 8601);
• версию текста согласия (если вы меняете политику — старые согласия истекают);
• конкретные категории, на которые пользователь согласился;
• идентификатор сессии (для возможности связать с действиями).

Хранится это в localStorage пользователя (для UX) и на вашем сервере (для доказательной базы). На сервер можно лить асинхронно через fetch — не блокировать рендер.

7. Возможность отозвать

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

5 запрещённых практик (dark patterns)

Я регулярно вижу одни и те же ошибки. Иногда это копия GDPR-баннера от западного решения, иногда — собственное «творчество» от подрядчика, который писал баннер «как все». Перечислю топ-5, отсортированные по частоте встречаемости на аудитах.

Pattern 1. Pre-checked галочки

В модалке настроек все три категории cookie стоят с галочкой «Включено» по умолчанию. Пользователь должен снимать галочки, чтобы отказаться. Это прямое нарушение требования об активном согласии: согласие подразумевает действие, а тут оно «вытащено» из пользователя бездействием. Штраф — ч. 4 ст. 13.11 КоАП (несоблюдение требований к согласию), от 100 тыс. ₽ для ЮЛ.

Pattern 2. Только кнопка «Принять»

Баннер показывает одну кнопку — «Принять все cookie». Кнопки «Отказаться» нет вообще. Альтернатива — закрыть вкладку. Это формальное лишение пользователя права на выбор. То же нарушение, та же статья.

Pattern 3. Cookie-wall без альтернативы

Сайт не показывает контент, пока пользователь не нажмёт «Принять». Никакого способа просмотреть страницу без согласия нет. РКН чётко обозначил: cookie-wall допустим только если у пользователя есть реальная альтернатива (например, платная подписка без рекламы и трекинга). Просто закрыть доступ — нельзя.

Pattern 4. Неравновес кнопок

Самая популярная ошибка из тех, что я вижу. Огромная зелёная кнопка «Принять все» на половину баннера, тонкая серая ссылка «Отказаться» или «Настроить» в углу мелким шрифтом. Технически выбор есть, но дизайн манипулирует пользователем. РКН считает это dark pattern и приравнивает к отсутствию выбора. На аудите 152-ФЗ я как раз это и проверяю — открываю баннер на телефоне в инкогнито и смотрю, можно ли вообще найти «Отказаться» за 3 секунды.

Pattern 5. Скролл-лок как согласие

В тексте баннера написано: «Продолжая просмотр сайта, вы соглашаетесь с обработкой cookie». Любое движение по странице автоматически считается согласием. Это запрещено напрямую: согласие требует активного действия, а скролл — это пользовательская навигация, а не выражение воли.

Cookie и Яндекс.Метрика в 2026

Самый частый вопрос: «Метрику нужно прятать за согласие?» Краткий ответ — частично. Расшифровываю.

Яндекс.Метрика с 2024 года поддерживает consent mode — режим работы с учётом согласия пользователя. Технически это означает, что счётчик можно разделить на две части:

• Базовая статистика — анонимные данные о визитах, без cookie с уникальным идентификатором посетителя. По позиции Яндекса и РКН, такая работа допустима без явного согласия пользователя. По сути это счётчик, который видит «зашёл человек» и больше ничего.
• Полная Метрика — с Webvisor, картами кликов, целевой аудиторией, поведенческими сегментами. Все эти возможности подразумевают идентификацию посетителя по cookie_id и поведению. Это — обработка ПД, требующая активного согласия.

На практике настройка такая:

1. Подключаете счётчик Метрики в режиме `params: { defer: true }` или с задержкой.
2. До согласия — отправляете только `ym(ID, 'hit', URL)` без cookie (для этого используете `'accurateTrackBounce'` без Webvisor и без clickmap).
3. После согласия на «Аналитику» — активируете Webvisor и clickmap отдельной командой `ym(ID, 'enableAll')` или похожей.

Что делать с Google Analytics

Я снимаю Google Analytics со всех клиентских сайтов с 2023 года. Причина — нарушение ст. 18 ч. 5 152-ФЗ: данные российских пользователей передаются в США без оформленной трансграничной передачи. Юридически GA — это передача ПД за рубеж, для которой нужно отдельное основание (отдельное согласие, не пересекающееся с cookie-согласием). На практике никто такого основания не оформляет, потому что это сложнее, чем переехать на Метрику.

Альтернативы для тех, кому Метрика мала по функционалу: Plausible Analytics (можно self-host в РФ), Umami (тоже self-host), Mango Office Analytics для звонков. Подробный разбор аналитики в РФ я планирую в отдельной статье.

Готовый код cookie-консент-скрипта

Привожу минимальный рабочий vanilla-скрипт без зависимостей. Закрывает все 7 обязательных элементов. Можно копипастить в проект и адаптировать стили.

<!-- HTML: баннер и модалка -->
<div id="cc-banner" class="cc-banner" hidden>
  <p>Мы используем cookie для работы сайта и аналитики посещений.
     Подробнее в <a href="/privacy_policy.html#cookies" target="_blank">
     Политике cookie</a>.</p>
  <div class="cc-buttons">
    <button data-cc="accept-all">Принять всё</button>
    <button data-cc="reject-all">Только необходимые</button>
    <button data-cc="open-settings">Настроить</button>
  </div>
</div>

<dialog id="cc-modal" class="cc-modal">
  <h3>Настройки cookie</h3>
  <label><input type="checkbox" checked disabled> Необходимые (всегда)</label>
  <label><input type="checkbox" id="cc-analytics"> Аналитика</label>
  <label><input type="checkbox" id="cc-marketing"> Маркетинг</label>
  <button data-cc="save">Сохранить выбор</button>
</dialog>

<script>
(function () {
  var KEY = 'cc_consent_v1';
  var POLICY_VERSION = '2026-05-19';
  var banner = document.getElementById('cc-banner');
  var modal  = document.getElementById('cc-modal');

  function load() {
    try { return JSON.parse(localStorage.getItem(KEY)); }
    catch (e) { return null; }
  }
  function save(consent) {
    consent.ts = new Date().toISOString();
    consent.version = POLICY_VERSION;
    localStorage.setItem(KEY, JSON.stringify(consent));
    // Зеркалим на сервер для доказательной базы:
    fetch('/api/cc-log', { method: 'POST',
      headers: {'Content-Type': 'application/json'},
      body: JSON.stringify(consent) }).catch(function(){});
    apply(consent);
    banner.hidden = true;
    if (modal.open) modal.close();
  }
  function apply(c) {
    if (c.analytics) enableAnalytics();
    if (c.marketing) enableMarketing();
  }
  function enableAnalytics() {
    // Активируем полную Метрику с Webvisor и clickmap
    if (window.ym) window.ym(YM_ID, 'enableAll');
  }
  function enableMarketing() {
    // Подключаем пиксели соцсетей и ремаркетинг
    var s = document.createElement('script');
    s.src = 'https://vk.com/js/api/openapi.js';
    document.head.appendChild(s);
  }

  document.addEventListener('click', function (e) {
    var t = e.target.closest('[data-cc]');
    if (!t) return;
    var a = t.dataset.cc;
    if (a === 'accept-all')  save({ analytics: true,  marketing: true  });
    if (a === 'reject-all')  save({ analytics: false, marketing: false });
    if (a === 'open-settings') modal.showModal();
    if (a === 'save') save({
      analytics: document.getElementById('cc-analytics').checked,
      marketing: document.getElementById('cc-marketing').checked,
    });
  });

  // Публичный API: window.ccReopen() — открыть настройки заново
  window.ccReopen = function () { modal.showModal(); };

  var saved = load();
  if (!saved || saved.version !== POLICY_VERSION) {
    banner.hidden = false; // согласия нет или устарело
  } else {
    apply(saved);
  }
})();
</script>

Что важно в этом коде:

• Сохраняется версия политики. Если вы поменяли cookie-политику — все согласия автоматически инвалидируются, баннер показывается снова. Это решает вопрос «что делать с предыдущими согласиями».
• Согласие зеркалится на сервер через `/api/cc-log` — это даёт вам доказательство в случае проверки. Минимальный endpoint на бэкенде пишет в БД timestamp, IP, user-agent и сами категории.
• Кнопки «Принять всё», «Только необходимые», «Настроить» — равной видимости. Стилизуйте их единообразно.
• Функция `ccReopen()` подключается к иконке/ссылке в футере, чтобы пользователь мог отозвать согласие.

Технические нюансы cookie

Часто люди думают, что cookie — это просто `document.cookie = "x=1"`. На деле там ворох настроек, которые влияют и на безопасность, и на правовые риски.

SameSite

Атрибут SameSite определяет, отправляется ли cookie при кросс-доменных запросах. Три значения:

• Strict — никогда не отправляется на сторонние домены. Безопасно, но ломает SSO и нормальную работу платёжных шлюзов.
• Lax — по умолчанию в современных браузерах. Отправляется только при top-level навигации (клик по ссылке), не отправляется в фоновых запросах.
• None — отправляется всегда, но обязательно вместе с `Secure`. Используется для third-party cookie (трекеры, пиксели).

Для cookie с согласием рекомендую `SameSite=Lax; Secure; HttpOnly` где это возможно. Для самого consent-cookie HttpOnly не подойдёт — нужно читать с клиента.

Secure и HttpOnly

`Secure` — cookie передаётся только по HTTPS. Обязательно для любых cookie с чувствительной информацией. `HttpOnly` — cookie недоступна из JavaScript, читается только сервером. Защищает от XSS-атак, при которых злоумышленник пытается украсть сессионную cookie скриптом.

Срок жизни

Cookie бывают session (живут до закрытия браузера) и persistent (живут до указанной даты Expires или Max-Age). Для согласия — persistent на 6–12 месяцев. Дольше — формально допустимо, но РКН не одобряет «вечные» согласия: считается, что человек должен иметь возможность пересмотреть выбор регулярно.

Third-party cookies в 2026

Google Chrome с 2024 года поэтапно отключает третьесторонние cookie. К концу 2026 года значительная часть пользователей Chrome будет работать без них вообще. Что это значит для вас:

• классический ремаркетинг через пиксели работает хуже — нужно переходить на server-side tracking;
• fingerprinting (отпечаток браузера) становится новым инструментом — а это в РФ тоже ПД, нужно согласие;
• first-party стратегия (собственная CRM, контакт-марафон, email-маркетинг) становится единственно устойчивой.

Что грозит за неправильный баннер

Статьи КоАП, по которым реально штрафуют за cookie-нарушения:

По моим наблюдениям, в 2024–2026 годах РКН вынес уже несколько сотен постановлений именно по cookie-нарушениям. Обобщённые сюжеты:

• интернет-магазин косметики с pre-checked галочками — 150 тыс. ₽ по ч. 4;
• сервис доставки с cookie-wall без альтернативы — 200 тыс. ₽ по ч. 4;
• образовательная платформа с Google Analytics без локализации — 1,5 млн ₽ по ч. 8;
• SaaS-сервис без cookie-баннера вообще, но с Метрикой и пикселями — 400 тыс. ₽ по ч. 1.

Самопроверка вашего cookie-баннера

Чек-лист на 12 пунктов. Хотя бы один «нет» — нарушение. Откройте сайт в режиме инкогнито с очищенным локальным хранилищем и проверьте.

Если получилось 10+ «да» — вы в безопасной зоне. 7–9 — нужны правки на пару часов. Меньше 7 — пора заказывать аудит сайта, проблем там точно больше, чем только cookie-баннер.

Частые вопросы (FAQ)

1. Нужен ли баннер для лендинга с одной формой связи?

Если на лендинге нет внешних скриптов (Метрика, пиксели, чаты, шрифты с Google Fonts) — формально не нужен. Но как только вы поставили хоть что-то из перечисленного — баннер обязателен. Я ещё не видел в дикой природе лендингов без Метрики, так что в реальности — нужен почти всегда.

2. Что если cookie ставятся только для логина в личный кабинет?

Это «необходимые» cookie — для них согласие не требуется, но в политике их нужно описать. Баннер тоже не обязателен, если других cookie нет. Однако в политике конфиденциальности должен быть отдельный раздел про cookie с перечислением: имя cookie, назначение, срок жизни, тип (session/persistent).

3. Считается ли cookie_id персональными данными?

В большинстве случаев — да. Позиция РКН с 2022 года однозначная: если cookie_id может быть сопоставлен с другими данными (через те же серверные логи, через привязку к авторизованному пользователю), это ПД. Судебная практика подтверждает (дело LinkedIn 2016, дело Booking 2022, ряд решений 2024-2025).

4. Можно ли использовать готовые консент-плагины (Iubenda, OneTrust)?

Можно, но осторожно. Большинство западных плагинов заточены под GDPR и не учитывают российскую специфику. Например, не пишут серверный лог в локальную БД (а вам нужно для проверки РКН), не поддерживают версию политики и пересогласие, не разделяют базовую Метрику и Webvisor. Из российских — есть Cookiebot.ru, CookieHub, но проще написать свои 60 строк vanilla, как в коде выше, чем разбираться с настройками чужого решения.

5. Что делать с предыдущими согласиями, если требования изменились?

Стандартная практика — при изменении политики обновляется поле `POLICY_VERSION`, и все ранее сохранённые согласия становятся недействительными (см. код выше — там это уже учтено). При следующем заходе пользователь видит баннер заново и пересоглашается с новой версией. Это и юридически чисто, и пользователю прозрачно.

6. Нужно ли логировать согласия и где их хранить?

Да, нужно. Хранить — в РФ, на тех же серверах, что и остальные ПД. Минимальный лог: timestamp, IP-адрес, user-agent, версия политики, конкретные категории согласия, идентификатор сессии. Срок хранения — не менее срока действия согласия плюс 3 года после отзыва (общий срок исковой давности). Удобно использовать отдельную таблицу `cookie_consents` в основной БД проекта.

7. Что если пользователь не нажимает ни одну кнопку — можно ли считать это молчаливым согласием?

Категорически нет. Молчание = отказ. До явного согласия не запускается ни один трекинговый cookie. Баннер может оставаться на экране до решения пользователя или быть закрытым автоматически с дефолтным «отказом». На практике большинство пользователей нажимают что-то в первые 5 секунд — это решается на уровне UX, а не правовым обходом.

8. Сколько действует одно согласие?

Закон не устанавливает чёткого срока. РКН в разъяснениях указывает на «разумный срок», который интерпретируется как 6–12 месяцев. Дольше — допустимо, но при условии что у пользователя есть постоянная возможность отозвать согласие. На практике рекомендую 12 месяцев с автоматическим пересогласием.

9. Что делать с iframe-виджетами (YouTube, ВК-виджет, чат)?

Iframe ставит cookie от своего домена — это third-party. Если этот виджет идентифицирует пользователя (а YouTube и ВК это делают), он требует согласия в категории «Маркетинг» или «Аналитика». Технически — не подгружать iframe до согласия. Можно показывать placeholder с кнопкой «Включить» и сообщением, что для просмотра нужно согласие на cookie третьих лиц.

Выводы

Cookie-баннер кажется мелочью, пока не получаешь предписание РКН и счёт на 300 тыс. ₽. По факту в 2026 году это базовая гигиена любого сайта — как HTTPS или политика конфиденциальности. Если резюмировать:

1. Сегодня: откройте свой сайт в инкогнито, пройдите 12 пунктов самопроверки. Если есть pre-checked галочки или Метрика стартует до баннера — это критичные баги, чините сегодня.
2. На этой неделе: внедрите минимальный консент-скрипт из этой статьи (60 строк), настройте Метрику в режиме разделённой работы (базовая до согласия, полная после).
3. В этом месяце: снимите Google Analytics, если он ещё стоит. Опишите cookie в политике конфиденциальности (имя, назначение, срок).
4. Один раз и навсегда: заведите серверный лог согласий и регламент пересогласия при обновлении политики.

Если на сайте больше одного нарушения сразу или вы не уверены, всё ли учли — закажите аудит 152-ФЗ. По итогу получите письменное заключение с конкретным списком правок и приоритетами. Цена — от 5 000 ₽ за лендинг, срок — 1–3 рабочих дня.

Вопросы по конкретной реализации на вашем стеке — пишите в Telegram. Я обычно отвечаю в течение часа, без формальностей.