Всем привет! Меня зовут Михаил Парфенов, я являюсь 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 баллов.

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

1. Уровень безопасности российских frontend-приложений является неудовлетворительным (39 из 100).

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

3. При защите веб-приложений в российских компаниях фокус смещен на защиту бэкенда (WAF, NGFW, API Security, сканеры уязвимостей, EDR и т.п.). Обеспечению безопасности frontend-части веб-приложений практически не уделяется внимания.

4. Низкий показатель безопасности в первую очередь связан с непониманием угроз (“приложение и так работает в браузере пользователя, что там взламывать?”).

5. Риски, связанные с frontend-приложениями, субъективно оцениваются низко.

6. Встроенные механизмы безопасности браузеров в российских приложениях не используются либо используются крайне неэффективно (оценка 7 из 100).

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

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

9. Контроль/управление изменениями при использовании тег-менеджеров, систем веб-аналитики должен осуществляться с участием ИБ-специалистов, т.к. такие сервисы используются злоумышленниками для сокрытия вредоносного кода / кражи данных.

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

11. Международные и российские регуляторы начинают включать требования по безопасности скриптов/frontend-приложений в требования (НСПК, PCI DSS 4.0.1) и рекомендации (НКЦКИ).

12. Более 70% российских компаний рискуют получить штрафы за нарушение 152-ФЗ “О персональных данных”, т.к. их сайты/frontend-приложения производят отправку данных пользователей за пределы РФ либо осуществляют сбор ПД с использованием баз данных, размещенных за пределами РФ (использование зарубежных систем веб-аналитики).

13. Утечка персональных данных в frontend-приложении либо невыполнение требований 152-ФЗ по трансграничной передаче ПД с 1 июля 2025 года могут привести к значительным штрафам для российских компаний: КоАП РФ 13.11 ч.8-9 от 1 до 18 млн. руб., КоАП РФ 13.11 ч.12-14 от 3 до 15 млн. руб.

14. Значительное число инцидентов, связанных с добавлением вредоносного кода в npm-зависимости frontend-приложений, показывает необходимость проведения анализа безопасности приложения в процессе безопасной разработки (РБПО, SSDLC, SDL, DevSecOps, FrontSecOps) до релиза.

15. Применение классических анализаторов безопасности SAST, DAST, SCA, OSA не снижает актуальные риски для frontend-приложений.

16. Применение классических средств защиты веб-приложений (WAF, NGFW, сканер уязвимостей) не снижает актуальные риски для frontend-приложений.

17. Инциденты, связанные с компрометацией сторонних js-сервисов и монетизации взлома бэкенда через добавление злоумышленниками вредоносных скриптов на frontend, показывают необходимость проведения регулярного анализа поведения приложения (например, каждые 6-12 часов).

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

19. Для обеспечения безопасности frontend-приложений необходимо использовать специализированные инструментов, например frontend-песочницы и/или системы мониторинга поведения приложения в реальном времени (Frontend Security Observability).

Рекомендации

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

2. Проверьте соответствие согласий на обработку ПД на сайтах, политик обработки ПД фактической ситуации (перечень третьих лиц, трансграничная передача ПД).

3. По возможности откажитесь от использования зарубежных систем веб-аналитики. Проверьте, отправлено ли уведомление о трансграничной передаче ПД в Роскомнадзор.

4. Разработайте модель угроз для frontend-приложений/веб-страниц. В сентября публиковал в telegram-канале @FrontSecOps примеры фреймворков и сервисов для моделирования угроз.

5. Проверьте, кто в компании имеет доступ к управлению тег-менеджерами, системами веб-аналитики. Внедрите процесс управления изменениями с согласованием ИБ.

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

7. При наличии в компании собственной разработки ПО внедрите этап проверки на безопасность frontend-части веб-приложений с помощью анализа поведения в процесс безопасной разработки, в идеале в виде автоматизированной проверки в CI/CD.

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

Заключение

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

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

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