Super App с мини-программами — это, по сути, операционная система внутри операционной системы. Хост-приложение загружает и исполняет код от сторонних разработчиков. Если этот код может читать данные других мини-программ или основного приложения — вся архитектура безопасности разваливается. Мы предлагаем реализацию изолированной песочницы под ключ, гарантируя, что каждая мини-программа работает в надёжно ограниченной среде. Это снижает риски финансовых потерь от утечек данных, которые могут достигать миллионов долларов. Пишите — оценим ваш проект за 1 день.
Почему изоляция мини-программ — технический вызов?
В WeChat Mini Programs, Grab SuperApp, Gojek — везде своя реализация изоляции. Главная проблема: нативный код в iOS и Android не умеет «изолировать» произвольный JS или Dart код без специальных механизмов. WebView даёт изоляцию DOM, но не изоляцию памяти и не ограничение сетевых запросов.
Типичный антипаттерн: загрузить JS мини-программы в WKWebView / WebView, открыть addJavascriptInterface для нужных API — и считать, что это песочница. Это не песочница. Любой XSS в мини-программе получает доступ ко всем объектам, зарегистрированным через addJavascriptInterface, включая мосты к нативному коду. Наш опыт показывает, что такой подход приводит к утечкам в 9 из 10 аудитов. Стоимость внедрения нашей песочницы окупается за счёт предотвращения подобных инцидентов.
Уровни изоляции, которые мы реализуем
Изоляция исполнения кода
На Android мини-программы на JS лучше выполнять в отдельном процессе через android:process атрибут в манифесте. Каждая мини-программа — отдельный процесс со своей heap. Крэш одной программы не роняет хост. Для Dart/Flutter — Isolate с ограниченным ReceivePort API.
Для WebView-based мини-программ: WebView с setJavaScriptEnabled(true) в отдельном процессе + WebViewClient с белым списком хостов:
class SandboxedWebViewClient( private val allowedHosts: Set<String> ) : WebViewClient() { override fun shouldInterceptRequest( view: WebView, request: WebResourceRequest ): WebResourceResponse? { val host = request.url.host ?: return blockRequest() if (host !in allowedHosts) { auditLogger.logBlockedRequest(miniProgramId, request.url) return blockRequest() } return null // продолжаем } private fun blockRequest() = WebResourceResponse( "text/plain", "UTF-8", ByteArrayInputStream("blocked".toByteArray()) ) } JavaScript Bridge с capability model
Вместо открытого addJavascriptInterface — декларативный мост с явным списком разрешений. Мини-программа запрашивает API, хост проверяет, разрешён ли он в манифесте этой программы:
class CapabilityBridge( private val miniAppManifest: MiniAppManifest, private val userId: String ) { @JavascriptInterface fun callNative(apiName: String, params: String, callbackId: String) { val capability = Capability.fromString(apiName) ?: run { sendError(callbackId, "UNKNOWN_API") return } if (!miniAppManifest.hasPermission(capability)) { auditLogger.logUnauthorizedApiCall(miniAppId, apiName) sendError(callbackId, "PERMISSION_DENIED") return } nativeApiRouter.dispatch(capability, params, callbackId) } } Манифест мини-программы описывает запрашиваемые API — аналог uses-permission в Android, только для mini app экосистемы.
Изоляция хранилища
Каждая мини-программа получает изолированный namespace в SharedPreferences и отдельную директорию в filesDir:
/app/mini_programs/ /{mini_app_id}/ /storage/ ← SharedPreferences namespace /files/ ← файловое хранилище /cache/ ← очищается при нехватке места Доступ к хранилищу другой мини-программы — только через явный Intent с подтверждением пользователя. Кросс-программный доступ к данным вне этой схемы — запрещён на уровне ContentProvider с проверкой callingUid.
Сетевая изоляция
На Android 8+ можно использовать ConnectivityManager с NetworkCapabilities для привязки конкретного соединения к VPN-профилю мини-программы. Менее агрессивный вариант — proxy с allowlist на уровне хоста и HTTPS pinning к серверам мини-программы через кастомный X509TrustManager. Мы также внедряем мониторинг количества запросов: лимит 1000 запросов в минуту на мини-программу, при превышении — блокировка с уведомлением.
На iOS — WKContentWorld (iOS 14+) позволяет выполнять JS каждой мини-программы в изолированном мире с отдельным глобальным объектом. Согласно документации Apple, это обеспечивает полную изоляцию контекстов выполнения.
let miniAppWorld = WKContentWorld.world(withName: "mini_app_\(miniAppId)") webView.evaluateJavaScript(miniAppCode, in: nil, in: miniAppWorld) { result, error in // код выполняется в изолированном контексте } Разные WKContentWorld не видят переменные друг друга даже в одном WKWebView.
Как обеспечивается доверенный запуск?
Перед запуском — верификация подписи бандла. Каждый бандл подписывается разработчиком и проверяется по публичному ключу, зарегистрированному на платформе:
fun verifyMiniAppBundle(bundle: ByteArray, signature: ByteArray, publisherKey: PublicKey): Boolean { val sig = Signature.getInstance("SHA256withECDSA") sig.initVerify(publisherKey) sig.update(bundle) return sig.verify(signature) } Запуск неподписанного или модифицированного бандла — отказ с логированием инцидента.
Мониторинг во время выполнения
Sandbox — не статическая конструкция. Нужен runtime мониторинг: время выполнения CPU per мини-программа, объём allocated памяти, количество сетевых запросов. Мини-программа, делающая 500 запросов в секунду, либо сломана, либо занимается майнингом.
На Android — Debug.MemoryInfo + Debug.ThreadCpuTimeNanos() для каждого процесса мини-программы. Пороги настраиваются в конфиге платформы (например, 200 мс CPU в секунду, 50 МБ памяти, 100 сетевых запросов в минуту).
| Уровень изоляции | Технология | Эффект |
|---|---|---|
| Исполнение | Отдельный процесс (android:process) / Isolate | Крэш не роняет хост |
| JavaScript мост | CapabilityBridge с манифестом | Контроль доступа к API |
| Хранилище | Namespace + ContentProvider | Изоляция данных |
| Сеть | WebViewClient allowlist / WKContentWorld | Ограничение запросов |
Что входит в работу
- Архитектурная документация схемы изоляции (процессы, мосты, хранилище)
- Реализация core-компонентов: SandboxedWebViewClient, CapabilityBridge, StorageManager
- Интеграция механизма аттестации бандлов с ECDSA-подписями
- Настройка runtime мониторинга с порогами CPU/память/сеть
- Аудит безопасности и пентесты песочницы перед запуском
- Поддержка и обучение команды в течение 2 недель после внедрения
Сроки и стоимость
Базовая песочница с WebView-процессной изоляцией и capability bridge — 2–3 недели. Полная платформа с сетевой изоляцией, аттестацией бандлов, runtime мониторингом и консолью управления разрешениями — 2–3 месяца. Стоимость рассчитывается индивидуально после оценки объёмов. Получите консультацию — свяжитесь с нами для бесплатного аудита. Закажите внедрение песочницы для вашего Super App — мы предоставим детальную оценку.