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.
Editorial analysis by NHI Mgmt Group, based on content published by Guardsquare: “When Restricted Doesn’t Mean Secure: Google API Keys in Mobile Apps”.
Key questions
Q: What should teams do when a mobile app must use a third-party API key?
A: Move the key off the client and into a backend proxy that your organisation controls.
Q: Why do app restriction checks still fail when the key is copied from a mobile app?
A: Because the restriction checks validate request metadata that an attacker can often extract and reproduce, such as bundle identifiers and certificate hashes.
Q: How do security teams know whether API edge protection is actually working?
A: Teams should look for lower rates of malicious requests reaching core services, faster detection of automated attack patterns, and fewer successful abuse cases such as credential sharing, account takeover, and inventory hoarding.
Practitioner guidance
- Remove high-value API keys from the mobile client Keep privileged Google API credentials only on a backend server and make the app call your own API instead of the third-party service directly.
- Treat client-side app restrictions as supplementary only Use package name, bundle ID, and certificate restrictions as a narrow filter, but assume an extracted key can still be replayed outside the intended app.
- Add app attestation before proxy access Require proof of genuine app instance before your backend issues a token or forwards the request to the external API.
Bottom line: Mobile app API keys should be treated as exposed credentials once they are shipped in the client, because restrictions that depend on request metadata can be spoofed.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:20 pm
Client-shipped API keys are a public-credential problem, not a mobile-only implementation flaw. Once a key is embedded in a distributable app bundle, the organisation has lost the basic assumption that the caller can keep the secret. That makes the issue structurally similar to other exposed NHI secrets: the boundary moved to the attacker’s device the moment the key shipped. The practitioner implication is to classify shipped API keys as recoverable credentials unless access is moved server-side.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What is the difference between obfuscation and backend control for API keys?
A: Obfuscation makes extraction harder, but the secret still ships with the app and can be recovered by a determined attacker. Backend control removes the key from the client entirely and forces the trust decision into infrastructure the organisation owns, which is the only durable way to prevent large-scale misuse.
👉 Read our full editorial: Google API keys in mobile apps need backend control, not trust