Спойлер: оба, но по-разному - и это важно понимать.

Каждый раз, когда слышим «у нас все нормально с безопасностью, мы же не банк», что-то внутри сжимается. За этой фразой обычно стоят токены аутентификации в SharedPreferences, SQL-запросы без параметризации и Firebase без правил доступа. Эта статья - попытка честно сравнить два мира, найти точки пересечения и разобраться, почему одни проблемы одинаковые, а другие - принципиально разные.

Исходные данные: OWASP Top 10 Web 2025, OWASP Mobile Top 10 2024, статистика NVD/CVE-базы, данные реальных пентестов, IBM Cost of a Data Breach 2024.

Масштаб проблемы: цифры, которые отрезвляют

По данным OWASP и NVD за последние годы картина не меняется кардинально - меняются только детали.

Инъекции стабильно лидируют по числу CVE среди всех веб-категорий. Проблема существует с 90-х годов, описана в каждом учебнике по безопасности - и все равно встречается в production-приложениях ежедневно.

Сбои аутентификации - credential stuffing, session fixation, отсутствие MFA на критичных операциях. По данным OWASP, уязвимости аутентификации встречаются в десятках тысяч приложений ежегодно.

Криптографические ошибки - MD5 для паролей, ключи в коде, TLS 1.0 на продакшене. Причем правильные решения существуют и хорошо задокументированы уже много лет.

Нарушения контроля доступа (веб) - по данным OWASP, выявляются в более чем 90% протестированных приложений. Именно поэтому эта категория занимает первое место в Web Top 10 третий рейтинг подряд.

По мобильным приложениям картина не радостнее. Исследования в рамках OWASP Mobile Security Testing Guide показывают:

• Большинство мобильных приложений содержат хотя бы одну уязвимость из Mobile Top 10 

• Небезопасное хранение данных (токены в незащищенных хранилищах, незашифрованные базы) - одна из самых частых находок при аудитах. 

• При статическом анализе APK захардкоженные API-ключи обнаруживаются значительно чаще, чем хотелось бы думать.

Последствия реальные: утечки персональных данных, финансовые потери, регуляторные штрафы (152-ФЗ, GDPR). По данным IBM Cost of a Data Breach 2024, средняя стоимость утечки данных составила 4,88 миллиона долларов, а среднее время обнаружения и сдерживания взлома - около 194 дней. И это без учета репутационного ущерба.

OWASP Top 10: детальное сравнение

Прежде чем идти в детали, посмотрим на оба списка рядом и сразу найдем общее.

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

В вебе уникальные угрозы сосредоточены вокруг серверной логики и наблюдаемости: ненадежный дизайн означает, что архитектурные просчеты закладываются еще на этапе проектирования бизнес-процессов и не поддаются патчингу без переписывания; сбои целостности ПО и данных бьют по CI/CD-пайплайнам и механизмам автообновления; а отсутствие нормального логирования и мониторинга делает атаку невидимой - злоумышленник может месяцами находиться внутри периметра, пока никто не смотрит в логи. Неправильная обработка исключений довершает картину: стектрейсы и внутренние сообщения об ошибках утекают в браузер, давая атакующему карту внутренней инфраструктуры.

В мобилке угрозы смещаются в сторону самого устройства и экосистемы приложения: небезопасное взаимодействие через незащищенные IPC-каналы, deep links и межпроцессные интенты открывает атаки, которых в вебе просто не существует; недостаточная защита бинарного кода позволяет реверс-инжинирить приложение, извлекать захардкоженные ключи и переупаковывать APK с вредоносной начинкой; недостаточный контроль конфиденциальности отражает специфику мобильных разрешений - геолокация, камера, контакты утекают через сторонние SDK незаметно для пользователя. Все это проблемы, которые веб-разработчик даже не рассматривает как вектор угрозы.

Архитектура определяет угрозы

Почему списки различаются - понятнее становится, когда смотришь на архитектуру.

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

При этом бэкенд общий - и мобильные, и веб-клиенты работают с одним API. Уязвимость на сервере опасна для обоих.

Общие уязвимости: где риски одинаковы

1. Аутентификация и авторизация

Это самый большой пласт проблем, одинаково актуальный для обеих платформ. Типичные ошибки:

IDOR - изменение чужих данных (мобильный API):

Безопасное управление сессией (PHP):

2. Инъекции

Встречаются везде, где есть пользовательский ввод и интерпретатор.

SQL-инъекция (Python):

XSS (JavaScript/PHP):

Инъекция в WebView (Android/Kotlin) - пересечение веб и мобилки:

3. Небезопасные зависимости (Supply Chain)

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

Как проверять зависимости (SCA - Software Composition Analysis)

Небезопасные зависимости легко ловить через SCA-подход - просто сканируйте дерево пакетов. В JS/Node.js запускайте npm audit, в Python - pip-audit, а в PHP - используйте встроенную команду composer audit или внешнюю утилиту local-php-security-checker. Добавьте Dependabot в репозиторий для авто-обновлений и настройте CI/CD так , чтобы сборка падала при High/Critical уязвимостях - это сильно снижает риски и дает спокойствие. Попробуйте на своем проекте, ждем результат.

Специфика мобильных приложений

Локальное хранилище: иерархия безопасности

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

Правильное хранение токена в Android (Kotlin) с использованием EncryptedSharedPreferences:

iOS - Keychain (Swift):

Certificate Pinning: защита сетевого трафика

Без pinning любой, у кого есть доступ к сети (или само устройство), может перехватить трафик через прокси.

Android Network Security Config (без кода):

Защита бинарного кода: уникальная мобильная проблема

В вебе исходники на сервере недоступны. В мобилке - APK можно скачать из магазина, декомпилировать через jadx и читать код почти как исходник на Java.

Специфика веб-приложений

Небезопасная конфигурация: инфраструктурные грехи

С ростом сложности инфраструктуры (Kubernetes, облако, микросервисы) неправильная конфигурация стала #2 в OWASP Web 2025. Примеры из реальной жизни:

Минимальный набор заголовков безопасности (Express.js):

Ненадежный дизайн: что не починишь рефакторингом

Это категория, которая появилась в OWASP 2021 и остается - потому что проблема реальная. Некоторые уязвимости возникают не из-за плохого кода, а из-за плохих архитектурных решений.

Пример: если система принимает цену товара от клиента, никакой input validation не поможет - нужно менять дизайн. Если механизм восстановления пароля основан на «секретных вопросах» - это дизайнерский провал.

Платформы: что дают, чего не дают

Выводы

Проблема не в платформе, а в подходе. Большинство уязвимостей - не экзотика. Хардкод ключей, отсутствие валидации, слабое хеширование - они существуют не потому что разработчики не знают как правильно, а потому что «работает же, потом поправим».

Бэкенд - общая точка ответственности. Мобильное приложение и веб-сайт могут работать с одним API. Если API уязвим к IDOR - оба клиента уязвимы. Безопасность серверной части важнее защиты конкретного клиента.

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

Supply chain - новая реальность. И в вебе (npm), и в мобилке (CocoaPods, Maven) зависимости - это внешний код, которому мы доверяем. Автоматическое сканирование (SCA) и SBOM - не опция, а необходимость.

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

Практический чек-лист

Для бэкенда (общий)

•  Параметризованные запросы или ORM везде, где есть пользовательский ввод

•  Авторизация проверяется на сервере, а не на клиенте

•  ID пользователя берется из токена, а не из тела запроса

•  Rate limiting на критичных эндпоинтах (логин, восстановление пароля)

•  Логирование событий безопасности с алертами

•  Регулярный аудит зависимостей (npm audit, pip-audit, dependabot)

Для веб-фронтенда

•  CSP без 'unsafe-inline' для скриптов

•  SameSite=Strict для авторизационных кук

•  HttpOnly + Secure флаги

•  CSRF-токены на формах изменения состояния

•  HSTS с includeSubDomains

•  Никакого innerHTML с пользовательскими данными

Для мобилки

•  Токены - только в Keystore/Keychain, не в SharedPreferences/UserDefaults

•  Certificate pinning с backup-пином и сроком обновления в календаре

•  R8/ProGuard на релизных сборках

•  FLAG_SECURE на экранах с чувствительными данными (защита от скриншотов)

•  Никаких секретов в коде - даже обфусцированных

•  Проверка на root/jailbreak - как доп. слой, не основной

Что почитать и поизучать дальше

• OWASP Web Security Testing Guide (WSTG) - исчерпывающее руководство по тестированию веба, бесплатно

• OWASP Mobile Application Security (MAS) - MASVS (стандарт) + MASTG (гайд по тестированию) + MAS Checklist

• OWASP MobSF - автоматический статический и динамический анализ мобильных приложений

• CWE/SANS Top 25 - список самых опасных классов уязвимостей независимо от платформы

• iOS Security Guide от Apple - официальная документация по механизмам безопасности iOS

• Android Security Guidelines от Google - официальные рекомендации для Android-разработчиков

• PortSwigger Web Security Academy - бесплатные практические лабораторные по веб-уязвимостям

Авторы статьи:

- Илья Новиков, технический директор @inova99

- Данил Мануйлов, Максим Быков, Линар Огай, Максим Савченко, тимлиды

- Тимофей Ищенко, техлид Frontend-разработки (направление web) @Is_Tim

- Даниил Николаев, Frontend-разработчик (направление web)

Если статья вам откликнулась - поделитесь в комментариях, какие неочевидные находки были у вас на пентестах и аудитах. Самое интересное в безопасности - именно нестандартные кейсы, которых нет в OWASP.