[REDACTED] — How to keep your mobile app’s secrets, a secret!
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
A practical guide to preventing mobile app secrets like API keys from leaking, covering four steps: scanning your codebase and git history for secrets using tools like gitleaks or the newer betterleaks, rewriting git history with BFG Repo Cleaner or git-filter-repo to purge them, restricting API keys via provider consoles (e.g. Google Cloud Console), and ultimately moving secrets off the client entirely via a backend proxy. It cites research showing over 55% of Android apps and 68% of top iOS apps have leaked secrets, and notes newer LLM-based tools can now outperform traditional secret-scanning methods used by attackers, raising the stakes further.
Table of contents
Correct your code 📝Get Ed Holloway-George ’s stories in your inboxI Switched from Gitleaks to Betterleaks — Here’s What ChangedLock down your secrets 🔐Better yet, just get rid of your secrets! 🗑️So, what next? 😎Thanks 🌟Questions this post answers
How do I remove secrets that were accidentally committed to a git repository's history, not just the latest commit?
Removing a secret from the latest commit is not enough because it still exists in git history; you need to rewrite history using a dedicated tool. BFG Repo Cleaner and git-filter-repo both accept a 'passwords' file listing secret strings and replace them with placeholders throughout history, though git's own filter-branch command is discouraged for being slow and error-prone. The process can take hours on large repos and forces all teammates to re-pull the rewritten history. Developers cleaning up leaked secrets can find tool comparisons and follow-up guides on daily.dev.
What tool can I use to scan a git repository for hardcoded secrets like API keys and tokens?
Gitleaks is an open-source CLI tool that scans a local git repo for common leaked secret patterns such as JWT tokens, AWS keys, and Google Cloud API credentials, and supports custom patterns. Its authors have shifted focus to a newer project called betterleaks, which offers better performance and quality-of-life improvements, run via a command like 'betterleaks git /path/to/repo -v --git-workers=16'. Track shifts like this between secret-scanning tools by following mobile security topics on daily.dev.
Why is it not enough to just remove hardcoded API keys from my app's build config using something like Gradle BuildConfig?
Injecting secrets via Gradle and BuildConfig at compile time keeps them out of source control, but they still end up baked into the compiled app binary and remain trivially accessible through decompilation. The more secure approach for published apps is proxying third-party API calls through your own backend, which stores secrets server-side and allows rotation without app downtime, while client-side restriction and injection methods only reduce, not eliminate, the attack surface. Weighing client-side secret injection against backend proxying gets easier with security deep dives on daily.dev.