Notifications
Clear all
Topic starter
19/08/2026 3:42 pm
TL;DR: Google API keys embedded in mobile apps can be extracted, spoofed, and reused even when application restrictions are enabled, so Guardsquare argues that obfuscation helps but only backend proxying and attestation actually reduce misuse. The core issue is that shipped API keys should be treated as public unless access is moved behind server-side control.
NHIMG editorial — based on content published by Guardsquare: When Restricted Doesn’t Mean Secure: Google API Keys in Mobile Apps
By the numbers:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
Questions worth separating out
Q: How should security teams protect API keys in mobile apps?
A: The safest pattern is to keep the API key off the device entirely and place sensitive API calls behind a backend proxy.
Q: Why do app restrictions fail to stop API key theft in mobile apps?
A: Because the restriction data is still derived from information an attacker can read from the app bundle and replay in a forged request.
Q: What breaks when an API key is shipped inside a mobile app bundle?
A: The key becomes recoverable by anyone who can inspect or automate extraction from the app package.
Practitioner guidance
- Move high-value API keys behind a backend proxy Keep the third-party API key only on a server you control, and let the mobile app call your backend instead of calling the API directly.
- Use app attestation for unauthenticated mobile experiences Where user accounts are not available, require attestation before the backend issues a token for API access.
- Apply obfuscation and RASP as delay controls Obfuscate embedded strings and use runtime application self protection to make scraping and reverse engineering more expensive.
What's in the full article
Guardsquare's full article covers the operational detail this post intentionally leaves for the source:
- Header-level request spoofing logic and why Google-style app restrictions can be replayed from extracted bundle metadata
- Practical comparisons between obfuscation, RASP, backend proxying, user authentication, and app attestation
- Implementation guidance for moving API calls behind a server-side control point without breaking mobile user experience
- Examples of when quota caps reduce cost spikes but still leave denial-of-service risk in place
👉 Read Guardsquare's analysis of why restricted Google API keys still fail in mobile apps →
Google API keys in mobile apps: are app restrictions enough?
Explore further
19/08/2026 4:20 pm
Client-side API keys create a trust problem, not just a secrecy problem. Once a secret is embedded in a mobile app, the app can no longer prove exclusive possession of that credential. That makes the key effectively reusable by anyone who can extract or replay it. For identity governance, the important shift is recognising that a credential shipped to an untrusted endpoint is already outside normal control boundaries. Practitioners should treat mobile-distributed API keys as exposure-prone assets, not as protected authenticators.
A question worth separating out:
Q: Who should control mobile API access when no user login exists?
A: The backend should control access through app attestation and server-side policy. Without a user identity, the system needs a reliable way to distinguish a real app instance from a repackaged client or a script. That makes attestation the practical substitute for user authentication in mobile proxy designs.
👉 Read our full editorial: Google API keys in mobile apps need backend control, not trust
