Безопасность Mini App для MAX: модель угроз и базовый чек-лист

Безопасность Mini App редко ломается из-за одной громкой ошибки. Чаще всё идёт тише: в логи попадает токен, фронт доверяет данным запуска без проверки, бот пересылает ссылку с лишним контекстом, staging держит старый секрет. Через пару месяцев продукт обрастает интеграциями — и на ровном месте возникает вопрос: а кто вообще проверял модель угроз.

Mini App в MAX живёт внутри платформы, запускается через бота, получает стартовые параметры, общается с backend, часто ведёт к оплате, заявке, документам или личным данным. Атаки здесь не ограничиваются банальным XSS: подмена контекста, фишинг на входе, утечки токенов через логи, слабый контроль доменов, ошибки с секретами, лишние доступы команды.

Нормальная security Mini App в MAX начинается с дисциплины: каким данным доверять нельзя, где хранить секреты, что не должно уезжать в лог, какие домены разрешены, как бот открывает Mini App, где проверяется контекст запуска, кто видит продовые доступы.

Ниже — практический материал про безопасность Mini App, защиту, типовые угрозы и чек-лист до запуска и после первых релизов. Официальные требования и API описаны на dev.max.ru; рекомендации по логам, CSP и секретам хорошо стыкуются с материалами OWASP.

Mini App в MAX подключается через бота и запускается внутри клиента. Для старта используется HTTPS URL, для передачи контекста — диплинки с параметром startapp. Внутри Mini App подключается MAX Bridge: доступ к window.WebApp, стартовым данным и объектам платформы.

MAX отдельно предупреждает: initDataUnsafe нельзя использовать для валидации пользователя — корректность стартовых данных нужно проверять через процедуру валидации на своей стороне (документация для разработчиков).

Эта деталь задаёт первую границу доверия: фронт получает удобный контекст запуска, истина про пользователя и права доступа должна подтверждаться сервером. Если Mini App верит стартовым параметрам на слово, защита трещит в начале сценария.

1. Фишинг и подмена входной точки — похожий сценарий через поддельную ссылку, фальшивый бот или изменённый маршрут.

2. Подмена контекста запуска — параметр startapp несёт полезную нагрузку; если backend не проверяет, что можно открыть и кому, появляется риск чужого заказа, анкеты или шага процесса. Размер payload в MAX ограничен, но проверка прав остаётся на вашем сервере.

3. Утечки токенов и секретов — чаще через логи, debug-выгрузки, переменные окружения в CI и скриншоты, чем через «хакерскую магию».

4. Слабый контроль доменов и внешних ресурсов — если фронт тянет скрипты и API-ответы откуда попало, поверхность атаки растёт быстро.

5. Избыточные права команды — безопасность начинает зависеть от памяти и удачи.

6. Плохой аудит действий — без фиксации, кто менял конфигурацию, открывал чувствительные кейсы и экспортировал данные, расследование превращается в поход с фонариком.

Модель угроз не обязана быть документом на сто страниц. Для первого прохода хватает простой схемы.

Активы:

• учётные данные пользователя;
• стартовый контекст запуска;
• токены сессии и служебные токены;
• персональные данные;
• платёжные и документные сценарии;
• журналы событий;
• секреты интеграций;
• права операторов и разработчиков.

Точки входа:

• кнопка запуска Mini App из бота;
• диплинк startapp;
• фронтовые формы;
• API backend;
• webhook и Bot API;
• CI/CD и конфигурация окружения;
• админки и мониторинг.

Основные сценарии атакующего:

• подмена payload при запуске;
• повторное использование ссылки на чужой сценарий;
• утечка токена в лог;
• исполнение чужого скрипта при слабой CSP;
• загрузка ресурса с постороннего домена;
• чтение чувствительных логов без нужной роли;
• использование старого секрета после увольнения или ротации.

MAX разделяет initDataUnsafe и валидацию: фронт — для рендера и быстрого старта, авторизацию, права и привязку к внутреннему профилю подтверждает backend.

Цепочка: Mini App получает стартовые данные → фронт отправляет их на сервер → backend проверяет подпись и валидность → сервер решает, кто это, что можно, какой сценарий открыть → фронт получает безопасное состояние.

Если шаг пропустить, сервис попадает в ловушку доверия к клиенту. Клиентская среда для security считается недоверенной: удобная и быстрая, но не источник истины.

OWASP по секретам: не хардкодить в коде, контейнерах и конфигурациях, которые легко утекут в CI, логи или репозиторий; хранить централизованно, ограничивать доступ, ротировать и журналировать использование; не класть секреты в логи в открытом виде; ротация — часть жизненного цикла, а не «праздник раз в полгода».

Для Mini App и backend:

• токены бота не живут во фронте;
• ключи внешних API не зашиваются в клиент;
• секреты — в менеджере секретов или защищённом хранилище;
• доступ — у сервисных аккаунтов с узкими правами;
• ротация по регламенту, старые значения удаляются;
• в логах и алертах — ссылка на факт использования, а не сам секрет.

OWASP: не писать в логи session id, access token, пароли, чувствительные ПДн, ключи шифрования и иные секреты; для корреляции — маскирование, хеширование, санитизация или шифрование; доступ к журналам ограничить, обращения к логам фиксировать и мониторить.

Привычки для защиты Mini App:

• продовые debug-логи выключены;
• payload запросов режется до безопасного минимума;
• токены и cookies маскируются до записи;
• session id заменяется хешем или внутренним trace id;
• ошибки внешних систем санитизируются;
• экспорт логов ограничен по роли и времени;
• журналируется чтение логов.

Для Mini App как веб-интерфейса контроль источников загрузки — практичная мера. OWASP по Content Security Policy рекомендует начинать с жёсткой политики и разрешать только необходимое — например, default-src 'none' с явным перечислением источников для скриптов, стилей, изображений, подключений и форм; учитывать form-action, frame-ancestors; по возможности отказываться от inline-скриптов.

На языке продукта: короткий allowlist доменов; connect-src до своих API и проверенных сервисов; ограничить img-src, script-src, style-src; frame-ancestors против лишних frame-сценариев; form-action для доверенных направлений. CSP не заменяет валидацию и безопасный backend, но режет XSS и подгрузку постороннего кода.

Аудит нужен, чтобы понимать, кто что делал, когда и с каким результатом.

Три зоны:

1. Административные действия — конфигурация, ротация секретов, allowlist, выдача прав.
2. Операционные — просмотр чувствительных сущностей, экспорт, смена статуса, доступ к кейсам клиента.
3. Разработческие — деплой, окружение, включение debug, изменение webhook.

OWASP для авторизации: least privilege, deny by default, права под задачу, регулярный пересмотр — не только после инцидента. Хорошая ролевая модель выглядит скучно — и это комплимент.

1. Меньше шансов на тихую утечку — токены и чувствительные поля не разбрасываются по логам, фронту и staging.

2. Проще проверка ИБ — на типовые вопросы уже есть ответ.

3. Дешевле сопровождение — роли, домены и контекст запуска описаны явно.

4. Спокойнее масштабирование — новые интеграции и релизы не ломают каркас защиты.

Как безопасность зависит от initDataUnsafe и backend-валидации?
initDataUnsafe не годится как корень доверия. Backend проверяет стартовые данные и только после этого решает вопрос авторизации, ролей и доступа к сценариям.

Какие угрозы связаны с диплинками startapp?
Payload — подсказка для сервера, а не доказательство прав. MAX задаёт формат и лимит длины, бизнес-логика доступа — на вашем backend.

Нужна ли CSP, если приложение внутри платформы?
Да: Mini App остаётся веб-интерфейсом со скриптами, стилями и запросами. Жизнь внутри MAX не отменяет правил веб-безопасности.

Как защититься от утечки токенов через логи?
Не логировать в открытом виде; убрать лишние payload и debug из прода; разделить техжурнал и бизнес-лог; маскирование, хеширование, контроль доступа к логам.

Какие доступы команды особенно опасны?
Широкий прод, общий сервисный аккаунт, чтение журналов без фиксации, ручной доступ к секретам, «временные» права без срока.

Нужна ли модель угроз для маленького Mini App?
Да. Маленький сервис не освобождён от атак. Достаточно короткого документа: активы, точки входа, доверенные и недоверенные границы, наиболее вероятные атаки — и решения по логам, доменам, токенам и доступам до релиза.

Где хранить секреты для Mini App и backend?
Не во фронте. Токены бота, ключи API и учётные данные — в защищённом хранилище секретов или контролируемом серверном контуре, с ротацией и журналированием использования.

Достаточно ли уровня защиты самой платформы MAX?
Нет: MAX упрощает интеграцию и задаёт ограничения, но валидация контекста, защита backend, секреты, логи, роли, CSP и аудит — зона ответственности вашего решения.

Что проверить перед запуском?
Валидируется ли контекст запуска на backend; не попадают ли токены, session id и чувствительные поля в логи; ограничены ли домены через CSP и allowlist; доступы по ролям; ведётся ли аудит чувствительных действий (деплой, конфиг, экспорт). Если в двух пунктах ответ «потом поправим», релиз лучше притормозить на день.

1. Проверяйте стартовые данные на backend.
2. Не доверяйте initDataUnsafe как корню идентичности.
3. Не храните секреты во фронте и репозитории.
4. Маскируйте токены и session id в логах.
5. Включайте строгую CSP и короткий allowlist доменов.
6. Держите роли узкими.
7. Журналируйте чувствительные действия.
8. Пересматривайте доступы и ротацию секретов регулярно.

Нужна помощь с моделью угроз, backend-валидацией и запуском Mini App в MAX — обсудим с командой Else Digital.

Безопасность Mini App складывается из небольших решений до релиза: проверка стартовых данных на сервере, хранение секретов, содержимое логов, разрешённые домены, кто видит прод, кто читает журнал, кто меняет конфигурацию. Хорошая модель угроз помогает увидеть сервис целиком — вход, границу доверия, ценные данные, вероятные ошибки и короткие пути для злоумышленника. Когда база собрана, защита перестаёт быть нервной импровизацией и становится частью архитектуры.

В «ОЧЕНЬ» через Mini App проходят платежи, поэтому модель угроз закрывали до запуска: роли разделены, данные проверяются на бэкенде, оплата идёт через провайдера, а не внутри клиента.