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 — мы предоставим детальную оценку.