Веб vs мобильная безопасность: сравнение рисков

На пентесте финтех-стартапа IDOR в API профиля нашёлся через Burp Suite из браузера за 20 минут - тупо подмена ID в GET /api/v1/users/{id}/profile. Через неделю та же команда декомпилировала APK мобильного клиента через jadx и обнаружила тот же IDOR, а рядом - захардкоженный API-ключ сервисного аккаунта с правами на запись. Два клиента, одно API, бэкенд без серверной валидации авторизации. По данным OWASP, нарушения контроля доступа обнаружены в 94% протестированных веб-приложений (A01:2021), а отчёт Quokka 2026 State of Mobile App Security показывает, что 94.3% Android-приложений до сих пор гоняют данные по незашифрованному HTTP. Уязвимости не живут на одной платформе - они мигрируют через общий API, и вопрос «где риски выше» упирается не в платформу, а в конкретную архитектуру.

Почему уязвимости повторяются на разных платформах: API как точка отказа​

Спор «риски веб безопасности выше или риски мобильной безопасности» - ложная дилемма. В большинстве продуктов веб-клиент и мобильное приложение обращаются к одному REST или GraphQL API. Уязвимость бэкенда ломает оба клиента одновременно.

Разница - в том, что видит атакующий при подготовке:


Серверная валидация - единственная реальная линия обороны в обоих случаях. Клиентские проверки - что в JavaScript, что в Kotlin/Swift - обходятся за минуты. OWASP API Security Top 10 (2023) ставит Broken Object Level Authorization (API1:2023) и Broken Authentication (API2:2023) на первые два места. Оба эксплуатируются одинаково вне зависимости от клиента.

Архитектурное отличие мобильного приложения: атакующий получает полный бинарник. Как отмечает NowSecure, 100% кода мобильного приложения исполняется на устройстве, которое атакующий контролирует - «your IP itself is not safe on that device, and you should assume that an application would be reversed». Для веб-приложения ~98% логики работает за firewall. Это не делает веб безопаснее - просто для мобильного приложения recon-фаза проще и информативнее: endpoint'ы, ключи и логика авторизации валяются в декомпилированном коде.

Масштаб проблемы: сторонний код составляет порядка 60% среднего мобильного приложения (исследование, представленное на RSAC 2025), и каждый SDK - потенциальный источник уязвимостей. IBM X-Force Threat Intelligence Index 2025 фиксирует среднее время между публикацией CVE и устранением - 29 месяцев. Почти два с половиной года. Известные уязвимости общего API эксплуатируются годами через оба клиента, пока кто-то наконец не обновит зависимости.

OWASP Web Top 10 vs OWASP Mobile Top 10: карта пересечений​

Сравнение двух списков (Web 2021 и Mobile 2024) показывает: примерно половина категорий - одна и та же проблема, описанная с учётом платформенной специфики.


Что уникально для веба. A04 (Insecure Design) - дефекты бизнес-логики на сервере. A08 (Software and Data Integrity) - компрометация CI/CD и механизмов обновления. A09 (Security Logging and Monitoring Failures) - атаки остаются невидимыми. A10 (SSRF) - серверные запросы к внутренним ресурсам. Всё завязано на серверную инфраструктуру и мониторинг.

Что уникально для мобильного. M5 (Insecure Communication - отсутствие pinning, cleartext-трафик). M6 (Inadequate Privacy Controls - камера, геолокация, контакты). M7 (Insufficient Binary Protections - обфускация, антиотладка). M9 (Insecure Data Storage - данные на устройстве в открытом виде). Здесь всё крутится вокруг устройства и того зоопарка, который на нём установлен.

Вывод для пентестера: тестирование только веб-клиента пропускает hardcoded secrets (M1), insecure local storage (M9) и binary protection gaps (M7). Тестирование только мобильного - пропускает SSRF (A10), logging failures (A09) и серверную injection chain. Полная картина рисков появляется только когда тестируешь обе точки входа.

Side-by-side: одна уязвимость - два вектора эксплуатации​

Хранение токенов: localStorage против SharedPreferences​

В вебе JWT кладут в localStorage - классическая ошибка. Любой XSS в приложении даёт атакующему прямой доступ к токену. На мобиле та же логика реализуется через SharedPreferences (Android) или NSUserDefaults (iOS). Оба варианта доступны при root/jailbreak, а SharedPreferences ещё и без root читается через adb backup, если в манифесте выставлен allowBackup=true (по умолчанию false начиная с Android 12 / API 31).

MASVS-STORAGE прямо требует: чувствительные данные - только в KeyStore (Android) или Keychain (iOS), зашифрованные, без доступа через backup. На практике это требование игнорируется с завидным постоянством.

Проверка на Android:
Аналогичная проверка в вебе - одна строка в DevTools Console:
По MITRE ATT&CK: Credentials In Files (T1552.001, Credential Access) для мобильного вектора, Credentials from Web Browsers (T1555.003, Credential Access) для веба. Один токен, одно API - два разных пути к нему.

BOLA: один запрос, разная разведка​

Broken Object Level Authorization (BOLA/IDOR) - первый номер в OWASP API Security Top 10 (API1:2023). Эксплуатация с обеих платформ идентична:
Через Burp Suite этот запрос одинаков что из браузера, что из мобильного приложения. Мобильный клиент иногда добавляет заголовки вроде X-Device-ID или X-App-Version, которые бэкенд якобы проверяет - на практике они декоративны, подмена ничего не меняет.

А вот что реально отличается: мобильный клиент часто использует endpoint'ы, которые не доступны через веб-интерфейс. Скрытые API-маршруты, debug-endpoint'ы, admin-функции - всё это обнаруживается при декомпиляции APK. На одном проекте мобильный клиент отправлял запросы на /api/internal/admin/users - endpoint без документации, без авторизации, невидимый из веб-клиента. Пентест только веба эту дыру бы не нашёл.

Hardcoded keys в мобильных приложениях​

У этой уязвимости нет прямого веб-аналога. В веб-приложении секреты живут на сервере - переменные окружения, Vault, .env-файлы, которые (в норме) не попадают в публичные assets. В мобильном приложении API-ключи, Firebase credentials и пароли сервисных аккаунтов регулярно зашивают прямо в код.

По данным Quokka (2026 State of Mobile App Security), hardcoded credentials обнаруживаются гораздо чаще, чем готовы признать команды разработчиков. Стандартный workflow: декомпиляция через jadx -d output app.apk, затем поиск через grep -rn "api_key\|secret\|password\|firebase" output/. MobSF автоматизирует процесс и генерирует отчёт с классификацией по OWASP MASVS.

По MITRE ATT&CK это Credentials In Files (T1552.001, Credential Access): атакующий получает учётные данные без единого сетевого запроса - просто анализируя бинарник. Для веба частичный аналог - поиск секретов в JS-бандлах через DevTools или через curl + grep по публичным assets, но вероятность находки ниже на порядок.

Reverse engineering как recon: уязвимости API мобильных приложений​

MASVS-CODE требует обфускации, удаления debug-символов и защиты от реверса. MASVS-PLATFORM покрывает риски IPC, deep links и WebView. На практике M7 (Insufficient Binary Protections) - одна из самых игнорируемых категорий. ProGuard/R8 включают с дефолтными правилами: имена классов обфусцируются, но строковые константы с ключами и URL остаются нетронутыми. Красивый фантик, а внутри - всё как на ладони.

Обход certificate pinning через Frida - штатная операция при тестировании безопасности мобильных приложений: frida -U -f com.example.app -l ssl_pinning_bypass.js. После этого весь трафик приложения идёт через Burp, и тестирование API мобильного клиента ничем не отличается от тестирования веб-клиента - те же запросы, тот же Repeater.

Pentest web vs mobile: инструментарий для обеих платформ​

При тестировании одного продукта по обоим векторам инструментарий пересекается сильнее, чем кажется:


Burp Suite - центральный инструмент, который работает одинаково на обеих платформах после настройки прокси. Для веба - конфигурация в браузере. Для мобильного - установка CA-сертификата Burp на устройство, настройка Wi-Fi proxy (или перенаправление через iptables на эмуляторе) и обход certificate pinning.

Мобильный стек сверху: Drozer для анализа Android IPC-компонентов (content providers, activities, broadcast receivers), Objection (построен на Frida) для iOS runtime exploration - обход jailbreak detection, дамп Keychain, анализ файловой системы. OWASP ZAP подходит для автоматизированного сканирования API-трафика обеих платформ.

Тестирование безопасности мобильных приложений - не отдельная дисциплина. Это расширение пентеста веба с добавлением фазы reverse engineering и device-level анализа. Методология OWASP WSTG покрывает веб-часть, OWASP MASTG - мобильную. MASVS задаёт требования верификации на трёх уровнях: L1 (baseline), L2 (defense-in-depth), R (resilience). В центре обеих методологий - API.

Сравнение угроз web и mobile через MITRE ATT&CK​

Маппинг на MITRE ATT&CK показывает, как одни и те же тактики работают через разные платформы:


System Information Discovery (T1082) на мобильном устройстве даёт атакующему куда больше контекста: модель, версия ОС, IMEI, список установленных приложений, геолокация, статус root/jailbreak. Веб-клиент ограничен User-Agent и fingerprinting через JavaScript API - разница в информативности ощутимая.

По данным Verizon DBIR 2025, 26% подтверждённых нарушений - веб-атаки, 38% утечек связаны с кражей учётных данных. IBM X-Force отмечает: ежедневно в тёмном вебе всплывает порядка 6000 свежих учётных записей. Эти credentials работают одинаково - что через веб-форму логина, что через мобильный API аутентификации.

Вопрос «безопасность веб и мобильных приложений - где выше?» не имеет универсального ответа. Если бэкенд не валидирует авторизацию - обе платформы уязвимы одинаково. Если мобильное приложение хранит секреты в APK - мобильный вектор опаснее, потому что даёт credential access без единого сетевого запроса. Если веб-приложение уязвимо к stored XSS - веб-вектор опаснее, потому что масштабируется через один URL на миллионы пользователей.

За пару лет работы на проектах, где один бэкенд обслуживает и веб, и мобильное приложение, я вижу одну системную проблему: команды разработки разделяют веб и мобильную безопасность на разные баг-трекеры, разные спринты, разных ответственных. API остаётся ничейной территорией. Одна и та же BOLA висит месяцами, потому что веб-команда считает это «мобильной проблемой», а мобильная - «серверной». Пять из семи критических находок на последних проектах оказались именно в этой серой зоне - endpoint, который обе команды считали «не своим».

Индустрия продолжает готовить пентестеров как «вебщиков» или «мобильщиков», будто это разные профессии. На деле - один набор уязвимостей API, просматриваемый через две линзы. Пентестер, который умеет только веб, пропускает hardcoded secrets и insecure storage. Пентестер, который умеет только мобайл, пропускает SSRF и server-side template injection. Полная цепочка собирается только когда оба вектора в руках одного человека или одной команды. Разделение на «веб-пентест» и «мобильный пентест» как отдельные услуги с каждым годом выглядит всё менее оправданным - клиенту не нужны два отчёта, ему нужна одна карта рисков API с учётом всех клиентов. Если хочешь повторить шаги в контролируемой инфре и собрать цепочку от BOLA до полного доступа - web-задачи на HackerLab покрывают именно этот класс уязвимостей с обоих векторов.