Всем привет! Меня зовут Михаил Парфенов, я являюсь Application Security-архитектором в DPA Analytics и автором telegram-канала @FrontSecOps. Сегодня я расскажу о результатах проведенного мной исследования безопасности российских frontend-приложений за первое полугодие 2025 года.

Цель исследования

Как правило при обеспечении информационной безопасности (ИБ) веб-приложений основное внимание уделяется защите серверной части (backend) приложения, в том числе используются решения класса WAF, NGFW, Anti-DDOS, EDR, VM и т.п.

Безопасности клиентской части приложения (frontend) уделяется значительно меньше внимания, т.к. frontend-приложения обычно выполняются вне контролируемой зоны - в браузере пользователя, являющимся “слепой” зоной для ИБ.

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

Отсутствие регулярного глубокого анализа поведения frontend-приложений и недостаточное внимание к безопасности клиентской части веб-приложений приводят к увеличению времени присутствия (недели, месяцы, годы) вредоносного кода и максимизации прибыли злоумышленников, которые все чаще выбирают в качестве цели именно frontend-приложения, что подтверждается известными инцидентами.

Целью данного исследования является оценка безопасности российских frontend-приложений, в том числе на основании определения эффективности использования механизмов безопасности браузера, зависимости от зарубежных сетей доставки контента (CDN), использования зарубежных систем аналитики, выполнения трансграничных передач персональных данных с веб-страниц и других факторов.

Объект исследования

В рамках исследования были проанализированы более 3100 публично доступных frontend-приложений крупнейших российских коммерческих компаний.

В течение одной минуты на странице эмулировались действия пользователя (скролл, движение мыши). Анализ не оказывал влияния/нагрузки на приложения и основан на общедоступной информации. Анализ проводился во 2-ом квартале 2025 года и включал приложения из следующих ключевых отраслей.

Определение общей оценки безопасности

Для определения уровня информационной безопасности frontend-приложений была разработана Общая оценка безопасности. Этот показатель определялся по 100-балльной шкале на основании множества критериев.

Критерии и их удельный вес приведены ниже.

Результаты. Общая оценка безопасности по отраслям

По результатам проведенного исследования общая оценка безопасности российских frontend-приложений по всем отраслям составила 39 из 100.

Ожидаемо, максимальный средний показатель оценки в категории Интернет-банки/ДБО - 77 из 100. Однако для такой критичной категории приложений это явно недостаточный показатель.

Так, например, некоторые системы ДБО загружают скрипты из-за рубежа, используют системы аналитики, осуществляющие избыточный сбор данных со страниц, не используют Content Security Policy и т.д.

Средняя оценка безопасности без учета Интернет-банков/Систем ДБО составляет 32 из 100.

Отдельно следует отметить, что уровень безопасности приложений из категории Банки/Финансы практически не отличается от других отраслей, что весьма критично, т.к. данные приложения являются одной из приоритетных целей для злоумышленников.

Наихудший показатель безопасности - в категориях Транспорт (18) и Телекоммуникации (20).

С учетом того, что многие категории приложений обрабатывают персональные данные пользователей, текущее состояние безопасности российских frontend-приложений следует признать неудовлетворительным.

Возможно, в компаниях нет понимания рисков, связанных с frontend-приложениями, и (или) анализ/инвентаризация скриптов/потоков данных вообще не проводится. Учитывая регулярные крупные инциденты с frontend-приложениями и запрет сбора персональных данных с использованием баз данных за пределами РФ с 1 июля 2025 года, ситуацию необходимо менять в кратчайшие сроки.

Результаты. Основные метрики

По результатам исследования было собрано множество различных метрик, например средний размер js-кода, среднее количество стран, в которые отправляются данные с веб-страниц, используемые API-браузера (WebAPI) и многие другие. Сводные данные по каждой отрасли доступны в полном отчете об исследовании (ссылка в конце статьи).

Ключевые риски

Далее будут кратко рассмотрены несколько “явлений”, влияющих на безопасность frontend-приложений, и их наличие в приложениях различных отраслей.

Подробное описание каждого "явления", анализ рисков и способы защиты описаны в полной версии отчета об исследовании, который опубликован в моем telegram-канале FrontSecOps: https://t.me/FrontSecOps.

1. Скрипты с зарубежных хостов

Скрипты на веб-странице могут быть подключены двумя способами: инлайн и в виде файла. В случае с инлайн-скриптами, код скрипта указывается прямо в теле страницы. В случае с файловыми скриптами указывается URL файла с JavaScript-кодом. При загрузке страницы браузер выполняет сетевой запрос для загрузки файла и исполняет полученный код.

Так, например, подключение библиотеки jQuery в виде файла в CDN (https://code.jquery.com/jquery-3.7.1.min.js, 85 КБ, Fastly CDN) экономило трафик к вашему серверу и в целом ускоряло загрузку веб-страниц за счет возможного кэширования при посещении других сайтов и географически распределенных серверов CDN.
Сегодня средний размер js-кода на странице составляет 3.3 МБ. Крупные компании используют собственные / платные российские CDN. Вашу jQuery давно пора “переместить” на свой сервер, т.к. загрузка скриптов с зарубежных хостов приносит не пользу, а только существенные риски для frontend-приложений.

2. Отправка данных на зарубежные хосты

С 1 июля 2025 года сбор персональных данных (ПД) с использованием баз данных, находящихся за пределами территории РФ, не допускаются (152-ФЗ, ст. 18, ч. 5), а с 2023 года запрещена трансграничная передача ПД без уведомления Роскомнадзора.

Идентификаторы пользователей, записанные в cookie, используемые для анализа поведения пользователей, признаются ПД регуляторами многих стран, в том числе в РФ.

Если на сайте установлен счетчик посещаемости или система веб-аналитики, то frontend-приложение обрабатывает ПД, даже если их нет на страницах в “явном” виде.

Даже при загрузке браузером картинки со стороннего сервера пользователю может быть установлен cookie для дальнейшего отслеживания интересов пользователя (по посещению других сайтов).

Сотрудники РКН могут проверить, в какие страны отправляют данные Ваши веб-страницы в рамках мониторинга, и сверить эту информацию с согласием/политикой обработки ПД на сайте. При несоответствии могут быть применены санкции регулятора.

3. Google Tag Manager (GTM)

Тег-менеджер - внешний сервис и размещаемый на веб-странице скрипт, который позволяет динамически добавлять на веб-страницы другие скрипты/фрагменты по определенным условиям (URL, время, регион, выполнение действия и другие).
Используется маркетологами для добавления кода разных скриптов систем аналитики на разные страницы или выполнения небольших скриптов “достижения цели” при определенных условиях.

Один из самых популярных сервисов - Google Tag Manager (GTM). Тег-менеджер - облачный сервис. Скрипты и условия их добавления на страницы конфигурируются в веб-интерфейсе Google.

С точки зрения ИБ тег-менеджер можно назвать “frontend-бэкдором”, который позволяет менять исходный код frontend-приложения по заданным условиям. Через GTM на страницы можно добавить js-снифферы, js-майнеры и другие вредоносные скрипты.
Часто доступ к консоли управления GTM есть только у маркетологов, а добавляемые скрипты не контролируются ИБ, что значительно снижает защищенность веб-приложения. В инциденте 2019 года злоумышленники размещали на страницах взломанных сайтов GTM, а через него уже добавляли js-сниффер при загрузке страницы в браузере. Это позволяло "замаскироваться" во время проведения ручного анализа кода приложения ("а, это скрипт GTM, у нас его маркетологи используют, значит всё хорошо").

4. Яндекс Метрика с вебвизором

Яндекс Метрика - российская система веб-аналитики. Используется на большинстве российских сайтов. По результатам данного исследования - на 72% frontend-приложений.
Вебвизор - модуль Яндекс Метрики, позволяющий просматривать запись сеансов пользователей практически в виде видеозаписи. Вебвизор собирает и отравляет на серверы Яндекса полный контент веб-страниц, движения мыши, нажатия клавиш пользователем и другие данные.

Использование вебвизора в frontend-приложениях, отображающих конфиденциальную информацию (личные кабинеты, CRM-системы, онлайн-банки, сайты с формами обратной связи), равносильно передаче такой информации на серверы Яндекса с возможностью просмотра в Яндекс-аккаунте, управляющим счетчиком (обычно доступ есть у маркетологов).Модуль вебвизор включен по умолчанию при создании счетчика Яндекс Метрики. В модуле может быть настроено исключение захвата определенного контента (например, таблица с ПД клиентов в CRM, однако для этого необходима тонкая настройка / указание атрибутов у элементов страницы, содержащих конфиденциальную информацию).
Злоумышленник может разместить на веб-страницах скрипт Яндекс Метрики с вебвизором для кражи данных с помощью данного легитимного инструмента.

5. Функция eval()

JavaScript-функция eval() предназначена для выполнения js-кода из строки.
Во многих инцидентах eval() используется злоумышленниками для динамической дешифровки вредоносного кода перед выполнением с целью сокрытия кода и затруднения анализа безопасности. В настоящее время практически отсутствуют обоснованные причины использования данной функции в js-приложениях, а ее использование значительно снижает защищенность приложения.

Функция eval() может легитимно использоваться сложными обфускаторами или, например, скриптами антифрод-систем для затруднения анализа кода злоумышленниками / конкурентами.Использование eval() в приложении делает невозможным настроить наиболее строгую Content Security Policy (CSP), что также снижает защищенность приложения и оставляет больше возможностей потенциальному злоумышленнику.
Статические анализаторы (SAST) имеют сложности как с анализом кода внутри eval(), так и с обнаружением фактов вызова eval() (например, конструкций вида window[‘ev’ + ‘al’](‘attacker code’)). Для этих целей эффективно применять frontend-песочницы.

6. (Не)использование Content Security Policy (CSP)

Content Security Policy (CSP) – механизм безопасности, позволяющий создателю frontend-приложения указать браузеру пользователя, из каких источников веб-странице разрешается загружать различные ресурсы (скрипты, картинки, шрифты и т.д.).
Также CSP позволяет контролировать целостность скриптов и других ресурсов посредством указания в HTTP-заголовке CSP разрешенных хэш-сумм; возможность использования функции eval(); разрешение инлайн-скриптов; хостов, с которыми веб-странице разрешается устанавливать сетевые соединения.

Важно! Даже при самой строгой CSP, в JavaScript-коде есть возможность отправки сетевого запроса с произвольными данными на любой внешний хост. То есть, если вредоносный код попал в frontend-приложение по любому из возможных векторов, у злоумышленника всегда есть возможность отправить украденные со страницы данные на свой хост (см. статью Content Security Policy (CSP) защитит от js-снифферов и утечек?, в статье приведен код стенда, на котором демонстрируется отправка данных с веб-страницы на сторонний хост при самой строгой CSP).

В реальных бизнес-приложениях “самой строгой” CSP практически не встречается. Если на веб-страницах установлена система веб-аналитики, то в CSP разрешается загрузка скриптов с соответствующего внешнего хоста. Этим могут воспользоваться злоумышленники для похищения данных через размещение своего счетчика данной системы аналитики (как в кейсе с Яндекс Метрикой с вебвизором).Также есть проблемы с разграничением ответственности внутри компании за настройку и контроль изменений CSP. Саму CSP формируют разработчики (т.к. хэш-сумма js-файлов фиксируется сразу после релиза), HTTP-заголовок может добавляться DevOps на уровне единой точки входа в приложение / реверс-прокси. CSP может быть отключена/ослаблена на этих уровнях, поэтому у ИБ / AppSec должен быть независимый контроль за изменением заголовков CSP.
В связи с этими проблемами и актуальностью угроз js-снифферов соответствующие требования были включены в стандарт PCI DSS 4.0.1 (действует с 31.03.2025): “11.6.1 Контроль изменений на платежных страницах, контроль изменения HTTP-заголовков, оповещение персонала о несанкционированных изменениях”.

7. Эффективность конфигурации Content Security Policy (CSP)

Само по себе наличие заголовка CSP не делает приложение безопаснее. Так, в рамках исследования были обнаружены приложения, в CSP которых не было указано ни одной “запрещающей” директивы либо такие директивы разрешали всё (*).

Для определения эффективности конфигурирования CSP была разработана методика оценки. Наиболее строгая конфигурация CSP (разрешающая обращения только на собственный хост и контролирующая целостность ресурсов по хэш-суммам) соответствует максимальной оценке (100). Далее за каждое исключение или ослабление CSP оценка снижалась.

8. (Не)использование Subresource Integrity (SRI)

Subresource Integrity (SRI) - механизм контроля целостности файловых ресурсов frontend-приложения (скриптов, стилей).

Разработчик frontend-приложения может указать в атрибуте integrity соответствующего тега (например, скрипта) хэш-сумму файла. После загрузки файла браузер рассчитает его хэш-сумму, если она не совпадет с указанной в атрибуте, то данный скрипт не будет выполнен.

SRI эффективен для контроля целостности файловых ресурсов, размещенных на сторонних серверах (например, в CDN), для защиты от несанкционированного изменения.

Важно! SRI не защищает от попадания вредоносного кода в frontend-приложение через npm-зависимости, добавления вредоносного кода в приложение при компрометации бэкенда и многих других векторов.
Также SRI не подходит для контроля целостности внешних js-сервисов (например, систем веб-аналитики), т.к. такие сервисы могут вносить изменения в свои скрипты без предупреждения в рамках развития функциональности.

Интерпретация общей оценки безопасности

Общая оценка безопасности рассчитывалась на основании критериев, которые снижают защищенность frontend-приложения, увеличивают поверхность атаки и расширяют возможности злоумышленников.

Контекст приложения / бизнес-требования при расчете оценки не учитывались, поэтому оценку необходимо правильно интерпретировать.

Само по себе наличие запросов на зарубежные хосты, наличие подключенного Google Tag Manager (GTM), вызовов eval() и другое не является инцидентом, если это является бизнес-требованием и вы знаете об их наличии.

Не снижает риск:

«Знаем конечно, у нас разрешено»;
«Да, у нас разрешена Яндекс Метрика с вебвизором»;
«Всё хорошо, у нас eval() не запрещен в CSP, т.к. он используется скриптом нашей антифрод-системы».

При таком подходе frontend-приложение по прежнему находится в “слепой” зоне для ИБ, и в случае попадания вредоносного кода по любому вектору вы можете узнать об инциденте только через недели/месяцы случайно, после жалоб пользователей или из СМИ.

Что снижает риск:

регулярный автоматизированный глубокий анализ поведения frontend-приложения;
контроль изменений;
оповещения персонала о несанкционированных изменениях;
проверка каждые 6-12 часов.

Это снижает риски, выводит frontend-приложение из “слепой” зоны, делает обнаружение инцидентов оперативным, а приложение - безопасным.

При применении такого подхода общая оценка безопасности вашего frontend-приложения может быть увеличена на 40 баллов.

Итоговые выводы

Уровень безопасности российских frontend-приложений является неудовлетворительным (39 из 100).
Несмотря на лучший показатель безопасности в категории онлайн-банки (77 из 100) по сравнению с другими отраслями, данная оценка является недостаточной с учетом уровня критичности данных приложений.
При защите веб-приложений в российских компаниях фокус смещен на защиту бэкенда (WAF, NGFW, API Security, сканеры уязвимостей, EDR и т.п.). Обеспечению безопасности frontend-части веб-приложений практически не уделяется внимания.
Низкий показатель безопасности в первую очередь связан с непониманием угроз (“приложение и так работает в браузере пользователя, что там взламывать?”).
Риски, связанные с frontend-приложениями, субъективно оцениваются низко.
Встроенные механизмы безопасности браузеров в российских приложениях не используются либо используются крайне неэффективно (оценка 7 из 100).
Работа frontend-приложений в “слепой” зоне для ИБ и низкая оценка рисков приводит к увеличению времени присутствия вредоносного кода в приложении и максимальной монетизации для злоумышленников.
Низкий уровень безопасности и множество способов монетизации делают frontend-приложения приоритетной целью для злоумышленников, что подтверждается регулярно обнаруживаемыми инцидентами.
Контроль/управление изменениями при использовании тег-менеджеров, систем веб-аналитики должен осуществляться с участием ИБ-специалистов, т.к. такие сервисы используются злоумышленниками для сокрытия вредоносного кода / кражи данных.
Масштаб утечек персональных данных через js-снифферы может быть сопоставим с компрометацией бэкенда за счет длительного времени присутствия вредоносного кода в приложении (недели, месяцы).
Международные и российские регуляторы начинают включать требования по безопасности скриптов/frontend-приложений в требования (НСПК, PCI DSS 4.0.1) и рекомендации (НКЦКИ).
Более 70% российских компаний рискуют получить штрафы за нарушение 152-ФЗ “О персональных данных”, т.к. их сайты/frontend-приложения производят отправку данных пользователей за пределы РФ либо осуществляют сбор ПД с использованием баз данных, размещенных за пределами РФ (использование зарубежных систем веб-аналитики).
Утечка персональных данных в frontend-приложении либо невыполнение требований 152-ФЗ по трансграничной передаче ПД с 1 июля 2025 года могут привести к значительным штрафам для российских компаний: КоАП РФ 13.11 ч.8-9 от 1 до 18 млн. руб., КоАП РФ 13.11 ч.12-14 от 3 до 15 млн. руб.
Значительное число инцидентов, связанных с добавлением вредоносного кода в npm-зависимости frontend-приложений, показывает необходимость проведения анализа безопасности приложения в процессе безопасной разработки (РБПО, SSDLC, SDL, DevSecOps, FrontSecOps) до релиза.
Применение классических анализаторов безопасности SAST, DAST, SCA, OSA не снижает актуальные риски для frontend-приложений.
Применение классических средств защиты веб-приложений (WAF, NGFW, сканер уязвимостей) не снижает актуальные риски для frontend-приложений.
Инциденты, связанные с компрометацией сторонних js-сервисов и монетизации взлома бэкенда через добавление злоумышленниками вредоносных скриптов на frontend, показывают необходимость проведения регулярного анализа поведения приложения (например, каждые 6-12 часов).
Ручной анализ поведения frontend-приложения неэффективен, а злоумышленники усложняют техники сокрытия вредоносного кода, в том числе с использованием легитимных скриптов (тег-менеджеры, системы аналитики).
Для обеспечения безопасности frontend-приложений необходимо использовать специализированные инструментов, например frontend-песочницы и/или системы мониторинга поведения приложения в реальном времени (Frontend Security Observability).

Заключение

На данный момент уровень безопасности российских frontend-приложений является неудовлетворительным. С учетом текущего ландшафта угроз и полученных результатов российские компании могут быть не готовы к эффективному обнаружению/предотвращению инцидентов в frontend-приложениях.

Часть результатов исследования может быть признаком наличия вредоносного кода в некоторых приложениях. Необходимо менять ситуацию, как минимум чтобы не получить штрафы от регуляторов, а лучше чтобы сделать приложения безопасными, защитить бизнес и наших пользователей.

Полные результаты исследования опубликованы в моем telegram-канале FrontSecOps: https://t.me/FrontSecOps.

Frontender`s Spectre

От favicon до криптографии: как мы уместили 167 рабочих инструментов в одном сервисе

Неудовлетворительно. Результаты исследования безопасности российских frontend-приложений Q2 2025

Что такое браузерный сэндбоксинг?