В 14 зафиксированных случаях cookie-трекеры банков в Европе и США отправляли данные клиентов рекламным и аналитическим платформам, причем иногда еще до выбора в cookie-баннере или даже после отказа от трекинга. Для банков это не просто неловкость на стыке маркетинга и веб-аналитики: когда сторонний пиксель оказывается рядом с ипотечной заявкой или формой открытия счета, у команды безопасности, юристов и разработчиков внезапно появляется один и тот же инцидент.
22 июля исследовательская компания Jscrambler опубликовала разбор таких сценариев, сообщает Dark Reading. По данным исследователей, в девяти компаниях из 14 трекинг срабатывал без корректно полученного согласия: либо до взаимодействия с баннером, либо после нажатия «отклонить все», либо даже при выборе режима только с обязательными cookie. Дальше данные уходили примерно дюжине сторонних сервисов, среди которых Google, Meta, TikTok, LinkedIn, AdSafety, Salesforce, Adobe и Yext.
Ключевая проблема здесь в том, что cookie-трекеры банков срабатывали не на безобидных витринах с описанием тарифов, а в местах, где пользователь вводит чувствительную информацию. Jscrambler приводит пример испанского банка: в процессе ипотечной заявки после согласия на cookie пиксель TikTok получал хешированные email и номер телефона пользователя через запрос к своему endpoint, который исходил из встроенного iframe на странице ипотеки. При этом TikTok, как пишет издание, не фигурировал ни в cookie policy, ни в privacy policy банка. Для клиента картина выглядит особенно неприятно: он читает политику, видит стандартный набор формулировок, а потом его данные все равно уезжают в рекламную экосистему, о которой ему никто толком не рассказал.
Другой кейс оказался еще жестче. У португальского банка во время открытия счета один из пикселей отправлял запрос в Evergage, ныне Salesforce Interaction Studio, причем email клиента передавался в URL вообще без хеширования. На следующих шагах того же сценария наружу уходили имя, возраст, португальский налоговый номер NIF и contact key из Salesforce Marketing Cloud. В еще одном примере португальский сервис потребкредитования отправлял в Google Analytics полный URL кредитной заявки с закодированными, но не зашифрованными деталями: суммой займа, сроком, признаком выбора страховки и другими параметрами. И вот здесь разговор про «маркетинговый тег» заканчивается. Если значение можно связать с конкретным человеком или финансовым намерением, это уже материал для комплаенса, расследования и неприятных вопросов от регулятора.
Отдельно неприятно то, что проблема, похоже, не всегда была результатом чьего-то осознанного решения «давайте пошарим побольше данных». Jscrambler спорит с привычной логикой крупных adtech-платформ, которые обычно перекладывают ответственность на владельца сайта: мол, вы сами настроили параметры пикселя, мы лишь принимаем то, что нам отправили. Исследователи указывают на более скучную и оттого опасную правду: часть функций вроде advanced matching включена по умолчанию и сама стремится собирать и хешировать контактные данные без явного действия со стороны владельца сайта. То есть банк может вставить стандартный пиксель, не собираясь передавать email клиента с ипотечной страницы, а платформа аккуратно сделает это за него. Для ИТ-команд это плохая новость: угроза живет не только в кастомном коде, который кто-то написал, но и в «дефолтно удобном» поведении сторонних SDK, тегов и iframe.
Именно поэтому история быстро выходит за рамки приватности в узком смысле. Руководитель security research в Jscrambler Гарет Боукер описал ее как одновременно privacy-проблему, security-проблему и third-party risk-проблему. По его словам, исследователи видели не только передачу персональных данных в URL и сторонние системы, но и признаки инвазивного device fingerprinting, а также probing локальных портов. Иными словами, на чувствительных страницах финансовых организаций исполняется код, который сама организация не пишет и не контролирует полностью. Для разработчиков это хороший повод пересмотреть старую культурную привычку считать фронтенд-трекинг чем-то второстепенным и чисто маркетинговым. Для CISO и CIO это напоминание, что карта внешних зависимостей давно не заканчивается облаком, CDN и npm-пакетами.
С регуляторной стороны картина тоже довольно прозрачная, и именно поэтому кейс выглядит особенно токсичным. В Европе поверх общей рамки GDPR работают ePrivacy Directive, DORA и требования PSD2 к безопасной обработке финансовой и платежной информации. Если трекинг запускается до согласия, не уважает отказ, ломается при переходе между субдоменами или тянет данные из форм с финансовыми сценариями, у банка появляется слишком много точек для претензий сразу. В материале также напоминают про штрафы 2020 года: французский регулятор наказал Google на 100 млн евро, а Amazon на 35 млн евро за установку рекламных cookie без ясного объяснения их назначения и до получения согласия. Финансовому сектору от этого не легче: требования к устойчивости поставщиков и к управлению операционными рисками у него как раз выше среднего.
Практический вывод для бизнеса и ИТ тут неприятно прямолинеен. Cookie-трекеры банков больше нельзя считать безобидным фрагментом на стыке маркетинга и аналитики, который живет своей жизнью в контейнере тег-менеджера. Jscrambler рекомендует мониторить runtime-поведение страниц, применять runtime-контроли, реально исполнять выбор пользователя по consent и отключать advanced matching и автоматический сбор там, где он не обоснован. Для российских и русскоязычных команд, работающих в финтехе, e-commerce и любом regulated digital, это еще и предупреждение на будущее: чем больше сайт зависит от сторонних пикселей, personalization-движков и «умных» виджетов, тем выше шанс, что следующую утечку организует не злоумышленник, а стандартная интеграция, которую никто не проверял до конца. Исходный материал Dark Reading доступен здесь: .