Notifications
Clear all
Topic starter
19/08/2026 4:05 pm
TL;DR: Mobile app research across more than 10,000 Android and iOS apps found hundreds of live credentials embedded in production builds, while LLM-assisted analysis identified thousands more hidden secrets that regex-based tools missed, according to Guardsquare and cited academic studies. The control problem is not just detection, but reducing on-device trust assumptions so leaked secrets have limited value.
NHIMG editorial — based on content published by Guardsquare: Why Mobile App Security Needs Both Scanning and Protection
By the numbers:
- In a 2025 study of 10,331 apps, researchers found 416 valid credentials across 65 services.
- LLM-based SecretLoc analysis scanned thousands of APKs and identified 4,800+ hidden secrets missed by traditional regex scanners.
Questions worth separating out
Q: How should security teams govern hardcoded secrets in mobile apps?
A: Security teams should treat hardcoded secrets in mobile apps as revocable access credentials, not code trivia.
Q: Why do embedded mobile secrets create such a large security risk?
A: Because once a binary is distributed, attackers can reverse engineer it, inspect memory, and extract values that were never meant to be public.
Q: What do teams get wrong about app obfuscation and secret protection?
A: They often assume obfuscation can compensate for poor secret handling.
Practitioner guidance
- Scan compiled mobile artifacts in CI/CD Run secret detection against APK and IPA outputs on every build, not just against source repositories.
- Eliminate embedded secrets wherever possible Move authentication and API calls behind backend-issued tokens or server-side mediation so the client does not carry reusable credentials.
- Limit the blast radius of unavoidable keys Constrain each credential with the narrowest possible scope, rate limits, origin restrictions, and usage monitoring.
What's in the full article
Guardsquare's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance on integrating secret scanning into mobile CI/CD pipelines and release checks.
- Operational detail on obfuscation, runtime integrity, and secure storage choices for Android and iOS apps.
- Examples of how to limit the blast radius of unavoidable client-side keys through scope and monitoring.
- Practical recommendations for handling false positives, release exceptions, and rotation workflows.
👉 Read Guardsquare's analysis of why mobile app security needs both scanning and protection →
Mobile app secrets leakage: are scanning and protection enough?
Explore further
19/08/2026 4:39 pm
Mobile app secrets are a non-human identity governance issue as much as an AppSec issue. API keys, OAuth tokens, and embedded service credentials behave like production identities once they ship in a binary. That means lifecycle, scope, and revocation matter more than whether the secret was discovered by a developer or an attacker. The practical conclusion is that mobile security teams should manage embedded secrets as governed identities, not incidental strings.
A question worth separating out:
Q: How do I know if mobile secret controls are actually working?
A: Look for three signals: fewer secrets in release builds, faster revocation of any leaked credential, and lower dependence on client-side keys in production. If app packages still contain live tokens or build exceptions never expire, the control is failing even if no incident has occurred yet.
👉 Read our full editorial: Mobile app secrets exposure needs both scanning and protection
