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.
At a glance
What this is: This article shows that Google API keys shipped inside mobile apps remain reusable by attackers, and that application restrictions alone do not stop spoofed requests.
Why it matters: Mobile teams, IAM leads, and app security practitioners need to treat client-side API keys as exposed credentials and move enforcement to backend-controlled trust checks.
Context
An API key in a mobile app is a credential, not a guarantee of caller identity. If the key is embedded in client code, attackers can extract it, copy the request metadata, and replay calls outside the intended app boundary.
That creates a governance gap for mobile API access: the security control is being enforced by information the client can read and mimic. The article is especially relevant where mobile apps depend on third-party APIs and where the same pattern appears in NHI governance, because a shipped key behaves like a weak, distributed non-human credential.
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. The app should authenticate to your server first, and the server should decide whether to call the external API, which lets you enforce user checks, rate limits, and app provenance before the request leaves your environment.
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. That makes them a consistency check, not a proof of legitimate app origin, so a stolen key can still be replayed from a script or repackaged client.
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. Effective protection should also show consistent policy enforcement across device types and clear visibility into traffic patterns at the network edge.
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.
Technical breakdown
Why application restrictions fail as a trust control
Google’s application restrictions compare request metadata such as bundle ID, package name, and certificate hash against values registered in the cloud console. That checks whether the request claims to come from a known app, but it does not prove that the request originates from an uncompromised app instance. If an attacker can read the app bundle, they can often recover the same identifiers and reproduce the headers. The control is therefore a caller-label check, not a strong trust boundary.
Practical implication: Treat app restrictions as a weak filter, not as proof that an API key is safe to ship.
Why obfuscation raises cost but does not remove exposure
Obfuscation and RASP make static extraction harder by hiding the key string and complicating reverse engineering. That changes the economics of abuse, especially against automated scrapers that target many apps quickly. But the key still exists in the client package, so a determined attacker can eventually recover it from runtime behaviour, memory, or instrumented execution. Security improves only in degree, not in kind, because the secret remains client-side.
Practical implication: Use obfuscation to slow opportunistic theft, but do not rely on it for high-value API access.
Why backend proxying changes the control boundary
A backend proxy moves the secret out of the mobile app and into infrastructure the organisation controls. The app then authenticates to your server, and your server decides whether to call the third-party API on the user’s behalf. That allows session checks, rate limits, tiering, and app attestation to happen before the expensive API call is made. The trust problem becomes one of server-side authorization and provenance, which is far easier to govern than client-held secrets.
Practical implication: Move privileged API access behind server-side enforcement whenever the key has material cost or abuse impact.
Threat narrative
Attacker objective: The attacker aims to reuse a stolen mobile API key to make unauthorised API calls at the victim’s expense while avoiding their own quota and cost.
- Entry begins when an attacker extracts a Google API key from a mobile app bundle or observes it in a request flow.
- Credential abuse follows when the attacker spoofs the app headers or reuses the key from a script or repackaged client.
- Impact occurs when third-party API calls are billed, quota is exhausted, or the victim app loses availability for legitimate users.
Breaches seen in the wild
- iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
- OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
App restriction checks create a verification illusion when the attacker controls the request. If the enforcement mechanism depends on package names, bundle identifiers, or certificate metadata that the client can reveal, the control is only screening for consistency, not authenticity. This is a trust-gap pattern, and it matters because many mobile teams mistake “restricted” for “protected.” The practitioner implication is to validate whether a control actually binds access to a server-held trust decision.
Backend proxying is the real governance control because it restores policy enforcement to infrastructure the organisation owns. Once third-party API calls pass through your backend, you can combine user authentication, app attestation, quota controls, and privilege gating before the external request leaves your environment. That is the point where identity, session, and authorization controls start to matter. The practitioner implication is to design API access as a server-governed workflow, not a client-held secret.
App attestation is most useful when the organisation needs to distinguish legitimate app instances from scripted or repackaged callers. It does not make the mobile client trustworthy by itself, but it gives the backend evidence about provenance and integrity before issuing access to expensive APIs. This is a stronger pattern than static client checks because it shifts the decision to a verifiable challenge-response flow. The practitioner implication is to pair attestation with backend authorization for any API whose misuse creates cost, quota, or fraud exposure.
From our research library:
- 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.
- Read next: API Key Management Guide
What this signals
Client-side API credentials create a trust boundary that attackers can inspect, copy, and replay. Mobile teams should assume that any secret shipped in an app bundle will eventually be treated as recoverable, which makes backend enforcement the real control point for third-party API usage.
Credential exposure in mobile apps is a governance problem, not just a reverse-engineering problem. When the app controls the secret, the organisation loses the ability to prove caller provenance before quota, cost, or sensitive data access occurs. That is why server-side policy and attestation matter more than simple hiding of the key.
API key offboarding remains a common weak point across identity programmes. 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. Mobile API exposure is one more reason to treat these credentials as governed lifecycle assets rather than static application constants.
For practitioners
- 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.
- Gate expensive API calls by user identity or tier If the app already authenticates users, tie third-party API usage to authenticated sessions and apply stricter limits to premium or high-cost operations.
- Obfuscate keys only as a delay control Use polymorphic string encryption or equivalent masking to slow automated key scraping, but do not treat obfuscation as the final control for high-value access.
Key takeaways
- 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.
- Obfuscation can slow automated extraction, but it does not change the fact that a high-value key still exists in the app bundle and can be recovered.
- Backend proxying, user authentication, and app attestation move the trust decision to infrastructure the organisation controls, which is the only durable defence for valuable API access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centers on API keys exposed inside mobile app bundles. |
| NHI-07 — Long-Lived Secrets | Shipped API keys persist in apps long after distribution, creating durable abuse risk. | |
| NHI-10 — Human Use of NHI | Developers are embedding machine credentials in software intended for user devices. | |
| Recommendation — Move sensitive API credentials out of client bundles and revoke any keys that must not be recoverable. Replace long-lived client secrets with server-held credentials or short-lived tokens where possible. Stop using client-distributed NHI secrets as if end users can be trusted to preserve them. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The issue is failed caller trust when a copied key can still authenticate requests. |
| Recommendation — Verify that authentication cannot be replayed from a copied client secret or spoofed request. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | API keys are authenticators whose lifecycle must be controlled and rotated. |
| Recommendation — Apply authenticator lifecycle controls to issue, rotate, and revoke API keys outside the mobile client. | ||
Key terms
- Application Restriction: Application restriction is a vendor-side binding method that limits an API key to specific app metadata such as package name, bundle ID, or certificate fingerprint. It can reduce casual misuse, but it does not prove the caller is truly the original application once the metadata is visible to attackers.
- Backend Proxy: A backend proxy is a server-controlled intermediary that receives requests from the app and forwards them to third-party services using credentials kept off the client. It shifts trust, logging, and revocation into a controlled environment where access can be authenticated and authorised centrally.
- App Attestation: App attestation is a trust decision that checks whether a mobile app and its device environment meet policy before sensitive actions are allowed. It can use device integrity, app integrity, and telemetry to decide whether requests should be trusted, restricted, or denied.
- Polymorphic Encryption: Polymorphic encryption is an approach that allows operations to be performed on encrypted data without first revealing the plain text. In practice, it is used to support queries, analytics, or AI workflows while preserving confidentiality. The design aims to keep sensitive fields protected even during active processing.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through the NHI Foundation Level course, the industry's only accredited NHI security programme. It helps practitioners connect credential lifecycle control to real-world access governance across human and non-human identities.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org