Exploiting Super-App Ecosystems: The Hidden Danger of Mini-App APIs

TLDR: Mobile super-apps often expose powerful, undocumented APIs to third-party mini-apps, creating a massive, overlooked attack surface. Researchers demonstrated how prototype pollution and hidden API invocation can bypass sandbox restrictions, allowing attackers to steal user credentials or execute unauthorized actions. Security teams must treat these mini-app bridges as high-risk entry points and implement strict, domain-based access controls.

Mobile super-apps have become the dominant interface for millions of users, bundling everything from ride-sharing to banking into a single, massive binary. While these platforms offer convenience, they introduce a complex, hybrid architecture that security researchers are only beginning to dissect. The core issue lies in the bridge between the super-app and its hosted mini-apps. These mini-apps are essentially web-based components running inside a native container, relying on a JavaScript bridge to access native device capabilities. When that bridge is poorly architected, the entire security model of the host application collapses.

The Mechanics of the Bridge

At the heart of this architecture is the JavaScript engine, typically V8 or JavaScriptCore, which acts as the intermediary between the mini-app’s JavaScript code and the super-app’s native logic. Developers often expose a set of APIs to these mini-apps to handle file operations, network requests, and hardware access.

The research presented at Black Hat 2025 highlights that these APIs are frequently implemented with insufficient access control. Specifically, the researchers identified that many super-apps fail to enforce proper Broken Access Control at the bridge level. If a mini-app can invoke a native function that was intended only for internal use, the sandbox is effectively bypassed.

Prototype Pollution as an Escalation Vector

One of the most effective techniques demonstrated for exploiting these bridges is prototype pollution. By manipulating the prototype of a base object, an attacker can inject malicious logic into the global scope of the JavaScript environment. This allows the attacker to override legitimate API methods with their own, effectively hijacking the communication channel between the mini-app and the native host.

Consider a scenario where a mini-app uses a standard includes method to check if an API is on a whitelist. By polluting the Array.prototype, an attacker can force this check to return false or true at will, bypassing the security filter entirely.

// Example of prototype pollution hijacking a whitelist check
Array.prototype.includes = function(search) {
    if (search === "forbidden_api") return true;
    return Array.prototype.includes.call(this, search);
};

Once the whitelist is bypassed, the attacker can invoke "hidden" APIs—functions that exist in the native code but are not documented for third-party developers. These hidden APIs often have higher privileges than the public ones, providing a direct path to sensitive data like user session tokens or local storage.

Identifying Hidden APIs

For a pentester or bug bounty hunter, the challenge is discovering these undocumented entry points. The researchers suggest two primary methods. First, static analysis of the JavaScriptCore bridge code can reveal the mapping between JavaScript methods and their native counterparts. Using tools like Ghidra to reverse-engineer the super-app binary often exposes the full list of available native functions, including those that are not exposed in the official developer documentation.

Second, dynamic analysis using Frida is invaluable. By hooking the bridge communication, you can observe which APIs are called during normal operation and, more importantly, attempt to call undocumented functions directly from the console. If the super-app does not perform rigorous input validation on the parameters passed through the bridge, you can often trigger unexpected native behavior.

Real-World Impact and Risk

The impact of these vulnerabilities is severe. Because the mini-app runs within the context of the super-app, a successful exploit can lead to full account takeover. If the super-app handles payments or stores personal identification, the attacker can potentially exfiltrate this data by leveraging the bridge to access the native file system or network stack.

During an engagement, focus your testing on the App.request or similar network-handling APIs. Check if the super-app allows the mini-app to send requests to arbitrary domains or if it fails to strip sensitive headers like Authorization when the request is redirected to a third-party server. This is a classic Server-Side Request Forgery (SSRF) scenario, but executed from the client-side bridge.

Defensive Strategies

Defending against these attacks requires a shift in how super-app developers view their bridge. The most critical step is implementing strict, domain-based access controls for every API exposed to the mini-app. Never trust the mini-app to perform its own security checks. The native host must validate the caller’s identity and the requested resource before executing any native function.

Furthermore, developers should adopt a "deny-by-default" approach for all bridge APIs. If an API is not explicitly required for a mini-app’s functionality, it should be completely inaccessible. Finally, consider implementing runtime integrity checks, such as object freezing, to prevent prototype pollution from modifying the environment’s core methods.

The super-app model is not going away, but the current state of bridge security is unsustainable. As researchers continue to find ways to break these containers, the burden is on the platform owners to treat their JavaScript bridges with the same level of scrutiny as any other critical network-facing service. If you are auditing these applications, stop looking at the UI and start looking at the bridge. That is where the real vulnerabilities are hiding.