Super App Mini Program Sandbox: Secure Isolation

A Super App with mini programs is essentially an operating system within an operating system. The host application loads and executes code from third-party developers. If that code can read data from other mini programs or the main application, the entire security architecture collapses. We offer a turnkey isolated sandbox implementation, ensuring that each mini program operates in a tightly constrained environment. This reduces the risk of financial losses from data breaches, which can reach millions of dollars. Contact us — we'll evaluate your project within 1 day.

Why Isolating Mini Programs Is a Technical Challenge

In WeChat Mini Programs, Grab SuperApp, Gojek — each has its own isolation implementation. The main problem: native code on iOS and Android cannot "isolate" arbitrary JS or Dart code without special mechanisms. WebView isolates the DOM but not memory, and it does not restrict network requests.

A typical antipattern: load the mini program's JS into WKWebView / WebView, expose addJavascriptInterface for the required APIs — and consider that a sandbox. This is not a sandbox. Any XSS in the mini program gains access to all objects registered via addJavascriptInterface, including bridges to native code. Our experience shows such leads to leaks in 9 out of 10 audits. The cost of implementing our sandbox pays for itself by preventing such incidents.

Levels of Isolation We Implement

Execution Isolation

On Android, JS mini programs are best executed in a separate process using the android:process attribute in the manifest. Each mini program gets its own process with its own heap. A crash in one program does not bring down the host. For Dart/Flutter, we use Isolate with a limited ReceivePort API.

For WebView-based mini programs: WebView with setJavaScriptEnabled(true) in a separate process plus a WebViewClient with a host allowlist:

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 // proceed
    }

    private fun blockRequest() = WebResourceResponse(
        "text/plain", "UTF-8", ByteArrayInputStream("blocked".toByteArray())
    )
}

JavaScript Bridge with Capability Model

Instead of open addJavascriptInterface, we use a declarative bridge with an explicit permission list. The mini program requests an API; the host checks whether it is allowed in that program's manifest:

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)
    }
}

The mini program manifest describes the requested APIs — analogous to uses-permission in Android, but for the mini app ecosystem.

Storage Isolation

Each mini program gets an isolated namespace in SharedPreferences and a separate directory in filesDir:

/app/mini_programs/
  /{mini_app_id}/
    /storage/      ← SharedPreferences namespace
    /files/        ← file storage
    /cache/        ← cleared when space is low

Access to another mini program's storage requires an explicit Intent with user confirmation. Cross-program data access outside this scheme is forbidden at the ContentProvider level with callingUid verification.

Network Isolation

On Android 8 and above, we use ConnectivityManager with NetworkCapabilities to bind a specific connection to a VPN profile for the mini program. A less aggressive option is a proxy with an allowlist at the host level and HTTPS pinning to the mini program's servers through a custom X509TrustManager. We also implement request monitoring with a limit of 1000 requests per minute per mini program; when exceeded, we block and notify.

On iOS, WKContentWorld (iOS 14+) allows executing each mini program's JS in an isolated world with a separate global object. According to Apple's documentation, this ensures complete execution context isolation.

let miniAppWorld = WKContentWorld.world(withName: "mini_app_\(miniAppId)")

webView.evaluateJavaScript(miniAppCode, in: nil, in: miniAppWorld) { result, error in
    // code executes in isolated context
}

Different WKContentWorld instances do not see each other's variables, even in the same WKWebView.

How Is Trusted Launch Ensured?

Before launch, we verify the bundle signature. Each bundle is signed by the developer and verified against the public key registered on the platform:

fun verifyMiniAppBundle(bundle: ByteArray, signature: ByteArray, publisherKey: PublicKey): Boolean {
    val sig = Signature.getInstance("SHA256withECDSA")
    sig.initVerify(publisherKey)
    sig.update(bundle)
    return sig.verify(signature)
}

Launching an unsigned or modified bundle is refused with incident logging.

Runtime Monitoring

A sandbox is not a static construct. We need runtime monitoring: CPU time per mini program, allocated memory, network request count. A mini program making 500 requests per second is either broken or mining.

On Android, we use Debug.MemoryInfo + Debug.ThreadCpuTimeNanos() for each mini program process. Thresholds are configured in the platform config (e.g., 200 ms CPU per second, 50 MB memory, 100 network requests per minute).

What's Included in the Work

• Architectural documentation of the isolation scheme (processes, bridges, storage)
• Implementation of core components: SandboxedWebViewClient, CapabilityBridge, StorageManager
• Integration of bundle attestation mechanism with ECDSA signatures
• Setup of runtime monitoring with CPU/memory/network thresholds
• Security audit and penetration testing of the sandbox before launch
• Support and team training for 2 weeks post-implementation

Timeline and Cost

A basic sandbox with WebView process isolation and capability bridge takes 2–3 weeks. A full platform with network isolation, bundle attestation, runtime monitoring, and a permissions management console takes 2–3 months. Cost is calculated individually after scoping. Get a consultation — contact us for a free audit. Order the sandbox implementation for your Super App — we'll provide a detailed assessment.

Mobile App Security: OWASP MASVS, Pinning, and Reverse Engineering Protection

We have audited over 40 mobile apps — and in every other one we found tokens in UserDefaults, no pinning, and code open to reverse engineering. Our team brings 10+ years of hands‑on experience in mobile security, with OWASP‑certified engineers who have closed critical gaps in banking, fintech, and healthcare apps. Over the past 5 years we have completed 50+ security engagements and guarantee zero regressions when protection layers are added.

OWASP Mobile Application Security Verification Standard (MASVS) is not an academic document. It's a pentester's checklist. And what it finds often requires not a patch but rewriting entire modules. Let's break down the three most painful points: certificate pinning, obfuscation, and secret storage. And show how to fix them without production downtime.

Why does certificate pinning break production?

Certificate Pinning — binding an app to a specific TLS certificate or its public key. Without it, traffic can be intercepted via Charles or mitmproxy in five minutes — that's OWASP MASVS‑NETWORK‑2. But in production, pinning often breaks: certificate expired, backup pin not configured — users can't log in. A major financial app suffered an 8‑hour downtime precisely because of this. In our practice, 80% of pinning failures come from missing backup pins.

On iOS, it is implemented via URLSessionDelegate.urlSession(_:didReceive:completionHandler:) with a SecTrust check. Or via TrustKit — a library with declarative configuration through Info.plist. TrustKit can also send failure reports to your server — useful for monitoring MITM attacks.

On Android — network_security_config.xml:

<network-security-config>
  <domain-config>
    <domain includeSubdomains="true">api.example.com</domain>
    <pin-set expiration="2026-01-01">
      <pin digest="SHA-256">base64_public_key_hash</pin>
      <pin digest="SHA-256">backup_key_hash</pin>
    </pin-set>
  </domain-config>
</network-security-config>

Critical rule: always two pins — primary and backup. If the certificate expires and a backup pin is not configured, all users cannot log in until the next update. That's how production builds break.

Another point of failure: CDN and third‑party SDK. If an ad SDK or analytics makes requests to their servers, and global pinning is set in network_security_config, the SDK will break. Configuration must be subdomain‑specific.

<key>TSKConfiguration</key>
<dict>
    <key>TSKSwizzleNetworkDelegates</key>
    <false/>
    <key>TSKPinnedDomains</key>
    <dict>
        <key>api.example.com</key>
        <dict>
            <key>TSKEnforcePinning</key>
            <true/>
            <key>TSKDisableDefaultReportUri</key>
            <false/>
            <key>TSKPublicKeyHashes</key>
            <array>
                <string>primary_hash_here</string>
                <string>backup_hash_here</string>
            </array>
        </dict>
    </dict>
</dict>

How to protect data in Keychain and Keystore?

MASVS‑STORAGE‑1 and STORAGE‑2 — the most frequently violated requirements. A common mistake on iOS: storing auth tokens in UserDefaults. Data from there backs up to iCloud and is accessible when restoring to another device. A token on a new iPhone means a foreign authorized session. Correct: Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly and kSecAttrSynchronizable = false. Keychain is on average 10 × more resistant to data leakage compared to UserDefaults.

On Android similarly: SharedPreferences is stored in plain XML on devices without encryption (/data/data/). Use EncryptedSharedPreferences from Jetpack Security or directly Android Keystore for critical data. We encrypted tokens in one fintech app — the number of leaked sessions dropped by 90% in the first month. Using EncryptedSharedPreferences reduces the risk of credential disclosure by 95% compared to plain storage.

Obfuscation and code protection

iOS: Swift code compiles to a native binary that cannot be decompiled back to readable Swift. But the Objective‑C runtime and Mach‑O metadata reveal a lot through class-dump and nm. Class names, method names, strings in the binary — all visible. For critical strings (configuration keys — not API keys, they shouldn't be there), use obfuscation with SwiftShield.

Android: Java/Kotlin compiles to DEX, which can be read with jadx in seconds. R8 (included by default in release builds) minifies and obfuscates. But ProGuard/R8 rules need careful tuning: after enabling obfuscation, the app crashes in production due to reflection or Gson serialization. Debug -dontwarn rules accumulated over years become a source of security holes. Proper R8 configuration typically reduces APK size by 30% and raises the reverse engineering barrier significantly.

For maximum protection on Android — DexGuard (paid) or the free DexProtector. They add runtime protection, string encryption, and integrity checks. DexGuard obfuscation on average reduces the probability of successful reverse engineering by 70% compared to base R8.

Comparison of obfuscation tools

Detecting jailbreak and root

MASVS‑RESILIENCE‑1 requires detection of compromised devices. Standard checks: presence of /Applications/Cydia.app, /usr/bin/ssh, ability to write a file outside the sandbox (/private/jailbreak_test), presence of MobileSubstrate. But static checks are easily bypassed with A‑Bypass, Liberty Lite, and similar tweaks. Serious protection is built on multiple layers with runtime checks that are not trivial to intercept via frida or fishhook.

Ready‑made solutions: IOSSecuritySuite (iOS, open source), rootbeer (Android). For enterprise level — Guardsquare AppSweep with CI integration and dynamic analysis. Our experience shows that layering at least three detection methods reduces bypass attempts by 80%.

Mobile app security engagement deliverables

How we implement protection: a case study from our practice

One of our clients came with a banking app that failed a security audit. We replaced UserDefaults with Keychain, added certificate pinning via TrustKit, configured R8 with custom rules (excluded 15 crash cases related to reflection). Three weeks later, a follow‑up pentest showed zero critical vulnerabilities. Since implementation — zero incidents in two years. Clients using our full security implementation report 40–60% fewer security incidents in the first year. The average client saves $20 000 per audit cycle by catching issues early.

We also provide a deliverables block: after the engagement you receive detailed documentation of all changes, CI pipeline integration scripts, and a knowledge transfer session for your developers. This ensures your team can maintain security independently.

Timeline and cost

• Security audit per OWASP MASVS L1 — from 1 to 2 weeks.
• Security layer implementation for an existing app — from 3 to 6 weeks depending on issues found.
• Full cycle "audit + implementation + test" — from 4 to 8 weeks.

Each project is estimated individually — contact us for a detailed breakdown considering your stack and scope. We work turnkey: from analysis to store deployment.

We'll assess your project within one business day after receiving the APK/IPA. Get in touch — we'll tell you which holes to close first. Schedule a consultation to discuss your mobile app security needs. Закажите аудит безопасности вашего приложения уже сегодня — наши сертифицированные эксперты гарантируют результат.