A study of 23 Android apps conducted by Check Point reveals that misconfigurations in the apps leaked sensitive data from more than 100 million users. All apps are available on the official Google Play store with downloads ranging from ten thousand to ten million.
According to the researchers, it is because the Android apps have not followed best practices when integrating and configuring third-party cloud services into their apps that has resulted in the exposure of millions of users’ private data.
App data should always be protected. It’s as simple as that.
According to Hackersnews, the researchers found that app developers embedded keys required for sending push notifications straight into the apps.
This could not only make it trivial for malicious actors to send rogue notifications to all users on behalf of the developer but could also be exploited to direct unsuspecting users to a phishing page, thus becoming an entry point for more sophisticated threats.
Several of the vulnerable apps tested also had the cloud storage keys embedded, potentially giving malicious actors access to for example email addresses, phone numbers, user screen recordings, private chats, and locations.
Furthermore, developers were left vulnerable. The misconfigurations also put the developer’s internal resources, such as access to update mechanisms, storage, and more at risk.
App data should always be protected. It’s as simple as that. Not obfuscated or hidden away, but protected. Luckily there are easy to deploy tools available to help app developers prevent information leakage.
App developers need proper solutions for securely storing and protecting app assets, both locally on the end-user device and inside a published app.
Yet despite the growing number of tools and guidelines available, many development teams still rely on insecure practices that were never designed to withstand modern threat models. Embedding secrets, such as API keys, cloud credentials, or access tokens directly into source code, continues to be a surprisingly common pattern, especially in mobile app development. In the context of Android, these secrets are often recoverable through reverse engineering or static analysis — meaning that attackers don’t even need direct access to a backend system to compromise sensitive data.
Once a malicious actor extracts a hardcoded cloud storage key or a Firebase credential from an app package (APK), they can often query the app’s backend services directly. If no further access controls are in place on the server side, this could expose entire user databases. In some cases, attackers have been able to manipulate app functions, such as resetting passwords, accessing private media files, or even impersonating users. Worse still, once these secrets are leaked, it’s not always easy to rotate them, particularly when they’re used across multiple apps or services.
This type of vulnerability underscores a broader issue in mobile application security: the false assumption that mobile apps are black boxes. In reality, every app that is distributed to a user is, in some sense, “open source” to an attacker. With easy-to-use tools such as JADX or Apktool, even amateur attackers can decompile apps and inspect the code, often with little resistance. Once inside, they can locate embedded secrets, understand app logic, and find potential exploits.
Beyond secrets leakage, the research from Check Point also highlights a worrying lack of input validation and security hygiene in how third-party cloud services are integrated. Misconfigured Firebase instances, for instance, have been a recurring issue in mobile security for years. These misconfigurations can expose read/write access to entire databases, without the attacker needing to log in or authenticate. If a database contains personally identifiable information (PII), the consequences can be severe — including GDPR violations and massive reputational damage.
To counter these threats, developers must treat mobile apps as part of a broader, distributed attack surface. Secrets management should be done using secure vaulting mechanisms and environment-specific access controls, not hardcoding. In cases where credentials must be embedded, techniques such as runtime injection from protected enclaves, encrypted storage, and code obfuscation can reduce risk — though none are foolproof alone. Defense-in-depth is key.
Additionally, app developers should implement runtime protections such as root/jailbreak detection, emulator detection, code integrity checks, and anti-debugging measures to hinder reverse engineering. These protections can’t stop all attacks but can dramatically raise the bar, especially for opportunistic attackers. Crucially, developers must also enforce proper server-side validation and access control. Even if an attacker gets hold of a credential, they shouldn’t be able to use it freely without further authentication.
Finally, automated scanning tools can be integrated into CI/CD pipelines to flag hardcoded secrets before code reaches production. Open-source tools like truffleHog, GitGuardian, and Checkov are popular for identifying exposed keys and misconfigurations early in the development lifecycle. Likewise, penetration testing — including mobile-specific tests — should be a routine part of release cycles, not an afterthought.
In an era where mobile apps are gateways to everything from banking to healthcare, the stakes are too high for lax security. As the Check Point study illustrates, something as seemingly minor as a misconfigured cloud service can open the door to data breaches affecting millions. App developers, security engineers, and product managers alike must treat secret management and cloud integration as foundational pillars of secure mobile development — not optional extras.
