Telegram Mini Apps Have a Storage Problem—and It Changes the Trust Equation for Web Apps
The fastest way to ship an app may also be the fastest way to inherit a trust problem.
Telegram Mini Apps are ordinary web applications delivered inside Telegram’s interface. They can launch instantly, use familiar HTML, CSS, and JavaScript, tap into host-provided identity and payment features, and even gain a Home Screen shortcut. For developers, that is an unusually short path from URL to app-like product.
But a newly published security study argues that the ecosystem’s storage practices have not kept pace with that convenience. Researchers screened 61 Telegram Mini Apps and successfully analyzed 37. Of those 37, 30 contained locally stored data that the researchers classified as a security concern. The findings included replayable session tokens, weakly protected secrets, and wallet recovery phrases that could enable account or asset compromise.
This is not a newly active zero-day announcement. It is a fresh publication of research that included responsible disclosure and remediation work before publication. That distinction matters: the immediate story is not that every Telegram Mini App is currently exposed. It is that a large, app-like web ecosystem developed a serious trust gap—and the repair still depends on third-party developers adopting safer platform capabilities.
What the researchers actually found
The TENET study, submitted on August 18, focused heavily on cryptocurrency and wallet Mini Apps because compromised credentials in that category can produce direct financial harm. The team built a tool that locates Telegram Mini App storage databases and checks them for authentication tokens, private keys, mnemonic phrases, encryption material, and other sensitive artifacts.
Among the 30 affected apps, the researchers reported that 17 exposed session tokens, JWTs, or similar replayable authentication artifacts. Five stored mnemonic recovery phrases without robust protection. Six used encryption whose keys or parameters were available beside the encrypted data or recoverable from application code, undermining the value of the encryption.
The threat model is important. The primary filesystem attack concerns desktop systems where malware or someone with user-level access can read Telegram’s local application data without rooting the machine. The researchers also demonstrated that an XSS flaw could expose data belonging to the vulnerable Mini App’s own origin. On mobile, normal operating-system sandboxing raises the barrier; the paper’s direct extraction tests required rooted or jailbroken access.
The sample also should not be inflated into an ecosystem-wide rate. It was popularity-weighted and intentionally emphasized financially sensitive apps. Only 37 of the 61 initially considered apps met the processing criteria. The result is strong evidence of a problem in the analyzed group, not proof that 81% of every Telegram Mini App is vulnerable.
The trust problem is bigger than local storage
A separate paper published five days earlier points in the same direction from a privacy angle. The TeleGapper study observed 278 working Telegram Mini Apps at runtime and compared outbound requests with the applicable privacy disclosures. It found that 165 apps, or 59.4% of the sample, contacted at least one third party not disclosed by the relevant policy.
The timing is especially revealing. According to the study, 85.5% of the apps with an observed disclosure mismatch contacted an undeclared third party during opening, before meaningful interaction. None of the 278 displayed an observable consent or opt-out mechanism at launch. These are the researchers’ measurements from a defined sample, not a legal judgment about every request, but they show how quickly an embedded web app can begin moving data.
Together, the studies expose the central trade-off of app-in-app distribution. Mini Apps retain much of the web’s speed and flexibility: developers control a live URL, update without redistributing a native package, and integrate standard web services. Yet users experience the product inside a trusted host, where the boundary between Telegram, the Mini App developer, and third-party services is easy to miss.
That visual continuity can create more trust than the underlying governance has earned.
Telegram’s response shows what a useful platform fix looks like
The TENET researchers say their responsible disclosure led Telegram to introduce SecureStorage and DeviceStorage APIs. Telegram’s current Mini Apps documentation lists both as Bot API 9.0 capabilities. SecureStorage is intended for tokens, secrets, and authentication state; on iOS it uses Keychain, while on Android it uses Keystore. DeviceStorage provides persistent application storage but should not be treated as a vault for sensitive credentials.
The researchers reran their tool against Telegram’s official Wallet after remediation and reported that its recovery mnemonic was no longer extractable in plaintext. That is meaningful evidence that a host-level capability can reduce risk when an app adopts it correctly.
It is not, however, an automatic ecosystem repair. The researchers explicitly did not generalize the Wallet result to third-party Mini Apps. Each developer still has to migrate sensitive data, rotate exposed credentials where appropriate, remove recoverable secrets from ordinary web storage, and review backend token behavior.
This is not a PWA failure—but PWA builders should pay attention
Telegram Mini Apps are embedded web applications, not conventional browser-installed PWAs. They run inside a host-controlled WebView and can receive platform context that an ordinary website would not automatically possess. Treating these results as proof that installed PWAs are inherently unsafe would be inaccurate.
The transferable lesson is narrower and more useful: installability does not turn browser storage into secure credential storage. A manifest, service worker, standalone window, or Home Screen icon can improve reach and app-like UX, but none of those features makes localStorage an appropriate home for private keys, recovery phrases, or long-lived bearer tokens.
Open-web distribution also lacks the implied review layer users associate with an app store. That is often an advantage—faster releases, direct customer relationships, no gatekeeper commission—but it puts more weight on visible origin identity, transparent data practices, secure authentication, and a credible update and incident-response process.
What web app teams should do now
- Inventory client-side secrets. Review localStorage, IndexedDB, cookies, caches, bundled configuration, and platform-specific storage bridges. Record which values grant access if copied.
- Prefer short-lived, revocable sessions. Avoid treating a persistent bearer token as harmless application state. Where the architecture allows it, keep sensitive session material server-managed and use appropriately protected cookies.
- Do not ship decryption material with the ciphertext. A key embedded in JavaScript or saved beside encrypted data is packaging, not meaningful protection against local extraction.
- Use host security APIs deliberately. In Telegram, evaluate SecureStorage for tokens and secrets, test behavior across supported platforms, and provide safe fallback behavior rather than silently downgrading to plaintext storage.
- Make third-party traffic legible. Audit analytics, advertising, payment, and support SDKs at page load as well as during interaction. Ensure disclosures describe what the running app actually does.
- Test the installed and embedded product. Security reviews that cover only the public website can miss storage, identity, and lifecycle behavior introduced by a standalone window or host WebView.
Who should care
Founders should care because distribution speed can become a liability if customers cannot tell who controls their data. Developers should care because ordinary web implementation choices take on higher stakes when the host supplies identity, payments, or financial context. Product teams should care because seamless UX can obscure moments when clear consent or security explanation is needed. Investors and platform partners should care because ecosystem growth without portable trust controls creates remediation costs that eventually land on the host.
What IndApp watches next
The next signal is adoption, not API availability. Telegram now documents a secure storage path, but the market needs evidence that third-party Mini Apps are migrating to it and that unsupported platforms fail safely. Independent retesting will matter more than another capability announcement.
We are also watching whether app-like web platforms make trust visible at the distribution layer: verified developer identity, understandable origin information, app-specific privacy disclosures, permission history, and security diagnostics that survive installation or embedding. The open web’s advantage is that a product can move from link to app without asking a store for permission. Its next competitive advantage must be showing users, just as quickly, why that app deserves to be trusted.
Further reading
Recent news
