reCAPTCHA и приватность — как соответствовать GDPR в 2026 году

Введение: конец «бесплатной и простой» защиты от ботов

Почти два десятилетия Google reCAPTCHA была стандартом де‑факто в сфере безопасности.

Однако 2025 год стал переломным: Google принудительно перевёл всех пользователей на ключи реализации в Google Cloud Platform, что радикально изменило технический ландшафт и усилило опасения по поводу приватности Google reCAPTCHA.

Эта миграция была не просто «технической уборкой». Она привела к новой модели тарификации — бесплатный уровень ограничен 10 000 проверками (assessments) в месяц — и закрепила юридическую реальность: reCAPTCHA не является GDPR‑совместимой «из коробки».

На фоне штрафов — например, санкции на €125 000 против Cityscoot в том числе за некорректное использование reCAPTCHA — европейские регуляторы дали понять, что воспринимают инструмент как инвазивного обработчика данных, которому требуется явное разрешение.

Для владельцев сайтов в 2026 году задача уже не сводится только к безопасности — теперь нужно юридически корректно проходить через сложные вопросы приватности Google reCAPTCHA.

Миграция 2025 года: последствия для приватности Google reCAPTCHA

Технический сдвиг

К началу 2026 года Google перевёл всех пользователей reCAPTCHA Classic на Google Cloud Platform.

Это означает, что владельцы сайтов теперь обязаны управлять reCAPTCHA через проект Google Cloud с привязанным платёжным аккаунтом — даже на бесплатных тарифах.

Критически важно, что расширенные функции (например, обнаружение мошенничества) теперь «заперты» за подписками Enterprise.

Юридические последствия

Миграция в Cloud создает архитектурные изменения с серьезными последствиями для приватности.

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

Хотя Google выпустил обновленное Дополнение по обработке данных (Data Processing Addendum), заявляя, что reCAPTCHA Enterprise обрабатывает данные только по инструкциям клиента, европейские регуляторы по‑прежнему скептически относятся к защите приватности reCAPTCHA, особенно из‑за передачи данных в США.

Кризис приватности Google reCAPTCHA: ключевые нарушения GDPR

Несовместимость reCAPTCHA и GDPR обусловлена архитектурными решениями. Чтобы понять нарушения приватности в reCAPTCHA, нужно разобрать конкретные регуляторные опасности.

1. Избыточный сбор данных

reCAPTCHA анализирует поведенческие сигналы далеко сверх того, что строго необходимо.

• Движения мыши, паттерны кликов и тайминг нажатий клавиш.
• Полные скриншоты браузера и IP‑адреса.
• Браузерный фингерпринтинг (плагины, разрешение экрана, часовой пояс).

Такая интенсивность нарушает принцип минимизации данных в GDPR.

В отличие от альтернатив на базе техники proof‑of‑work, reCAPTCHA строит поведенческие профили, создавая существенные риски для приватности.

2. Отсутствие прозрачности

Операторы сайтов не могут полноценно выполнить требования статьи 13 GDPR, поскольку Google скрывает, какие именно данные собираются.

Баварское ведомство по надзору за защитой данных (Bavarian State Office for Data Protection Supervision) отмечало, что из‑за этой непрозрачности соблюдение требований по приватности reCAPTCHA фактически становится невозможным, поскольку оператор не может информировать пользователей об обработке данных, которую сам не до конца понимает.

3. Трекинговые cookies и согласие

reCAPTCHA устанавливает постоянные cookies (например, _grecaptcha) для межсайтового отслеживания. Согласно Директиве ePrivacy и GDPR, для этого требуется предварительное явное согласие. Если пользователь отказывается от cookies, скрипт не должен загружаться, что ломает работу формы и вынуждает пользователя обменивать приватность на доступ — это нарушение требования «свободно данного» согласия.

4. Трансграничная передача данных

Данные передаются на серверы в США и подпадают под действие законов о наблюдении, таких как FISA. Несмотря на EU‑U.S. Data Privacy Framework, европейские регуляторы сомневаются, достаточно ли мер защиты приватности в reCAPTCHA, учитывая, что бизнес‑модель Google опирается на тот самый поведенческий анализ, который используется для риск‑скоринга.

Почему «законный интерес» не защищает от проблем с приватностью reCAPTCHA

Дело Cityscoot 2023 года — ключевой прецедент. Французский регулятор (CNIL) оштрафовал компанию на €125 000 за нарушения GDPR, в том числе за использование reCAPTCHA без согласия пользователей. Cityscoot утверждала, что инструмент необходим для обеспечения безопасности. Однако CNIL отклонил этот довод, указав, что доступ reCAPTCHA к данным устройства пользователя требует предварительного согласия в соответствии со статьей 82 Закона Франции о защите данных.

Это решение подтверждает: отсылки к «безопасности» не освобождают reCAPTCHA от обязательного получения согласия от пользователя, если инструмент использует данные устройства пользователя.

Чек‑лист: как защитить приватность при использовании reCAPTCHA

Для организаций, которые не могут сразу отказаться от reCAPTCHA, следующие шаги обязательны, чтобы снизить юридические риски.

1. Блокируйте скрипт до получения согласия

Если вашей правовой основой является согласие, ваша CMP (Consent Management Platform) должна предотвращать загрузку https://www.google.com/recaptcha/api.js (и, следовательно, grecaptcha.js), пока пользователь явно не согласится.

Во Франции такой подход соответствует трактовке CNIL статьи 82 Закона о защите данных (правила в духе ePrivacy про «терминальное оборудование»), которая в целом требует предварительного согласия, когда инструмент получает доступ к информации на устройстве пользователя или сохраняет её и при этом не является строго необходимым для предоставления услуги, запрошенной пользователем.

Одна лишь «визуальная» блокировка (например, показ неактивного виджета) часто недостаточна, потому что скрипт может уже выполняться и взаимодействовать с браузером пользователя ещё до согласия.

2. Перейдите на reCAPTCHA Enterprise и подпишите DPA

Обновитесь до reCAPTCHA Enterprise и подпишите Google Cloud Data Processing Addendum (DPA). В отличие от бесплатной версии, в Enterprise‑контрактах прямо указано, что данные используются для безопасности и предоставления услуги, а не для персонализированной рекламы.

Хотя Google обязуется обрабатывать данные в основном по вашим инструкциям, имейте в виду, что использование «для улучшения сервиса» остается серой зоной для регуляторов ЕС.

Подписанный DPA демонстрирует должную осмотрительность, но не гарантирует соответствие — особенно в части передачи данных в США, — поэтому это инструмент снижения рисков, а не «щит».

3. Опишите политику конфиденциальности и cookie‑политику максимально детально

Ваши пояснения в документах о приватности должны по пунктам указывать:

• Какие данные собирает reCAPTCHA: IP‑адрес, движения мыши, тайминг нажатий клавиш, браузерные отпечатки, настройки устройства, установленные плагины, скриншоты, cookies.
• Зачем они собираются: «риск‑скоринг для обнаружения ботов и предотвращения мошенничества».
• Как долго данные хранятся: публичная документация Google даёт мало конкретики; зафиксируйте ваше допущение или запросите информацию у Google напрямую.
• Где обрабатываются данные: «серверы Google в США».
• Кто имеет доступ: «Google и авторизованные субобработчики (subprocessors)».
• Ссылка на Политику конфиденциальности Google: требуется по собственным условиям Google.

Кроме того, в cookie‑политике нужно явно указать cookie _grecaptcha и его назначение. Не прячьте это в общих формулировках — дайте отдельное, конкретное объяснение.

4. Получайте явное opt‑in согласие

Согласие на cookies должно быть:

• Подтверждающим действием (checkbox по умолчанию не отмечен, не «предвыбран»).
• Гранулярным (reCAPTCHA выделена среди других несущественных cookies).
• Отзываемым (пользователь может отозвать согласие и иметь механизм отказа).
• Документируемым (храните логи согласий с временными метками для аудита).

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

5. Задокументируйте DPIA (оценку воздействия на защиту данных)

В соответствии со статьёй 35 GDPR обработка, создающая высокие риски для прав пользователей, требует DPIA. Учитывая поведенческий трекинг reCAPTCHA и передачу данных в США, проведение DPIA настоятельно рекомендуется. Задокументируйте:

• Необходимость: почему требуется поведенческий мониторинг вместо менее инвазивных методов.
• Альтернативы: почему решения proof‑of‑work (например, Friendly Captcha) были отклонены.
• Смягчение уязвимостей: ваши конкретные меры (DPA, блокировка скрипта, логи согласий).

Эта документация станет вашей «страховкой» при проверках, доказывающей, что вы применяли подход privacy‑by‑design.

Почему организации отказываются от Google reCAPTCHA из‑за рисков приватности

Рост затрат и юридических рисков подтолкнул рынок к CAPTCHA‑провайдерам, изначально ориентированным на GDPR.

Ниже рассмотрим три примера таких провайдеров и сравним их подходы.

Friendly Captcha

• Происхождение: Германия (ЕС).
• Технология: Proof‑of‑work (устройство пользователя выполняет криптографическую задачу).
• Сбор данных: нет трекинговых cookies, нет постоянных идентификаторов пользователя.
• Размещение данных: вся обработка выполняется в ЕС; без передачи в США.
• Соответствие GDPR: privacy/GDPR‑совместимость заложена в архитектуру; предоставляется стандартный DPA.
• Пользовательский опыт: незаметно для пользователя; не нужно решать капчи.
• Стоимость: бесплатно для некоммерческого использования; прозрачные тарифы для бизнеса.
• Кейcы: используется госструктурами и enterprise‑компаниями для соблюдения строгих требований по суверенитету данных.
• Преимущества: устраняя поведенческий анализ (трек мыши, профилирование истории), Friendly Captcha убирает основной триггер несоответствия GDPR. Поскольку решение работает без трекинговых cookies и постоянных идентификаторов, баннер согласия на cookies по ePrivacy, как правило, не требуется. Архитектура «privacy‑by‑design» существенно упрощает соблюдение требований по сравнению с поведенческими инструментами.

Cloudflare Turnstile/Challenge

Cloudflare Turnstile — это замена CAPTCHA, которую вы встраиваете прямо в формы и пользовательские сценарии, тогда как Cloudflare Challenge — это «шлюз» на уровне edge/WAF, который блокирует или проверяет трафик ещё до того, как он попадёт в ваше приложение.

Turnstile может использоваться как один из типов проверок внутри более широкой системы Cloudflare Challenges, но эти инструменты работают на разных уровнях и решают разные задачи.

Технология Cloudflare Turnstile

• Что это: встраиваемый виджет, который проверяет «легитимность» пользователя и возвращает токен для серверной валидации.
• Как работает: оценивает окружение браузера, характеристики устройства (фингерпринтинг) и поведенческие паттерны (движения мыши, тайминг нажатий клавиш, паттерны запросов), после чего выдаёт токен верификации.
• Где применяется: защита на уровне приложения для пользовательских действий (регистрация, вход, оформление заказа).
• Влияние на UX: обычно работает незаметно; использует ненавязчивые проверки и Private Access Tokens (PAT), чтобы минимизировать явные челленджи.
• Сбор данных: поведенческий анализ (движения мыши, тайминг нажатий клавиш, паттерны запросов) + фингерпринтинг устройства (WebGL, User-Agent, разрешение экрана, плагины); не собирает полные скриншоты страниц и полную историю браузинга, но всё равно требует согласия по GDPR при поведенческом трекинге.

Технология Cloudflare Challenge

• Что это: механизм на уровне edge/WAF, который применяет проверки безопасности к запросам до того, как они достигнут вашего origin.
• Как работает: запускает фоновые JavaScript‑проверки (Proof‑of‑Work, фингерпринтинг устройства) и переключается на интерактивные проверки только при необходимости.
• Где применяется: периметровая защита трафика и эндпоинтов (защищает сам доступ к ресурсу).
• Связь с Turnstile: Turnstile можно выбрать как метод проверки в рамках экосистемы Cloudflare Challenges.

Происхождение: США.

Размещение данных: инфраструктура в США (Global Anycast); сертификация в рамках EU‑U.S. Data Privacy Framework.

Соответствие GDPR: поддерживается DPA; Cloudflare выступает как обработчик (processor), но также хранит данные как независимый контролёр (controller) для улучшения детекта ботов; данные не используются для рекламного ретаргетинга (в отличие от Google).

Стоимость: бесплатно до 20 виджетов (неограниченное число проверок); официальных ограничений для бизнес‑использования нет, но продукт позиционируется как «hobby tier» без SLA; для масштабирования свыше 20 виджетов нужен Enterprise без промежуточного тарифа (минимум $2,000+ в месяц).

Преимущества: значительно менее навязчиво, чем reCAPTCHA v2 (нет визуальных головоломок); не «собирает» данные для рекламы; интегрируется с WAF для комплексной защиты от ботов.

Недостатки: юрисдикция США; поведенческий трекинг (мышь, клавиатура, паттерны) всё ещё требует согласия; разрыв в ценовом позиционировании для mid‑market (бесплатно или $2,000+ Enterprise); пользователи с VPN/прокси нередко сталкиваются с дополнительными затруднениями.

ALTCHA

• Происхождение: open‑source сообщество (возможно локальное размещение).
• Технология: Proof‑of‑Work (PoW) + опциональная ML‑фильтрация спама.
• Сбор данных: нулевой; нет cookies, нет фингерпринтинга, нет трекинга.
• Размещение данных: self‑hosted на вашей инфраструктуре (полный контроль) либо управляемый SaaS API.
• Соответствие GDPR: полностью совместим по умолчанию; self‑hosting исключает сторонние потоки данных.
• Пользовательский опыт: «невидимый» или One‑Click; работает в фоне или через простой checkbox, без картинок‑головоломок.
• Стоимость: бесплатно (лицензия MIT) при self‑hosting; платные подписки для managed API/Sentinel и enterprise‑функций.
• Преимущества: максимальная приватность и суверенитет данных; self‑hosting убирает зависимость от стороннего обработчика и необходимость согласовывать DPA.
• Недостаток: self‑hosting требует DevOps‑ресурсов на развертывание и сопровождение. Не подходит командам без экспертизы в администрировании серверов.

Пошаговый план действий на 2026 год

1. Проведите аудит текущей реализации.
   • Проверьте, завершили ли вы cloud‑миграцию с Classic‑ключей.
   • Проверьте настройки CMP: блокирует ли она скрипты reCAPTCHA до получения согласия.
   • Поднимите аналитику: какой процент пользователей отклоняет cookies.
2. Рассчитайте реальный GDPR‑риск.
   • Оцените юрисдикции: есть ли пользователи в зоне активного контроля CNIL (Франция), странах‑участниках EDPB, в Австрии, Германии.
   • Изучите свежие решения органов по защите данных в вашем регионе.
   • Проконсультируйтесь с DPO (специалист по защите данных): есть ли у организации документированная DPIA.
3. Если вы остаетесь на reCAPTCHA — внедрите меры соответствия GDPR.
   • Обновите политику конфиденциальности с детальными раскрытиями по данным.
   • Настройте блокировку скрипта grecaptcha.js в CMP.
   • Согласуйте/подпишите Google Cloud DPA для версии Enterprise.
   • Проведите DPIA и сохраните документы.
   • Ведите логи согласий пользователей с горизонтом 12 месяцев для аудита.
4. Если вы мигрируете с reCAPTCHA — спланируйте переход.
   • Оцените Friendly Captcha, Cloudflare Turnstile/Challenge, ALTCHA или аналогичное решение под ваш сценарий.
   • Протестируйте альтернативу на staging‑окружении.
   • Проведите A/B‑тест в production: сравните конверсию заполнения форм до и после замены.
   • Запланируйте коммуникацию: уведомите пользователей, если вы убираете бейдж reCAPTCHA.

Заключение: «приватность по умолчанию» — новый стандарт

Миграция Google в Cloud в 2025 году обнажила ключевую проблему: инвазивный поведенческий анализ несовместим с GDPR.

Теперь перед владельцами сайтов стоят три пути.

• Ориентация на соответствие GDPR: перейти на Friendly Captcha, Cloudflare Turnstile/Challenge, ALTCHA или аналогичное решение, чтобы убрать регуляторные риски и упростить стек приватности.
• Управляемый риск: оставить reCAPTCHA Enterprise, но внедрить строгие меры соответствия (DPA, блокировка скриптов до согласия, DPIA).
• Отказ от CAPTCHA: полностью убрать CAPTCHA и использовать другие механизмы защиты от ботов (rate limiting, поведенческий rate limiting, анализ репутации IP).

Для большинства организаций первый вариант — наиболее разумный. “Приватные по умолчанию” альтернативы теперь конкурентоспособны по цене и снимают тяжёлую нагрузку по управлению согласиями и юридической защите. На фоне GDPR‑штрафов риск держаться за устаревшие инструменты перевешивает выгоды. Переход на решения «приватность по умолчанию» становится регуляторной неизбежностью, и принятие оперативных мер для операторов сайтов гарантируют безопасность в преддверии грядущей волны ужесточения контроля.

Тестирование новых платформ

По мере миграции на альтернативы вроде Friendly Captcha или Turnstile критически важно проверить, что уровень защиты сайта от ботов остается высоким. Поэтому инструменты вроде CapMonster Cloud могут быть полезны на этапе перехода.

Имитируя автоматизированный трафик и пытаясь решать ваши новые CAPTCHA‑проверки (включая reCAPTCHA Enterprise, Cloudflare Turnstile/Challenge, ALTCHA), CapMonster Cloud помогает QA‑команде оценить эффективность защиты до полного вывода в production. Это помогает убедиться, что движение в сторону соответствия GDPR не снижает ваш уровень безопасности.

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