Google API keys in mobile apps need backend control, not trust

At a glance

What this is: This is an analysis of why mobile app API key restrictions can be bypassed and why backend proxying changes the security model.

Why it matters: It matters because IAM, NHI, and application security teams need to treat embedded keys as governable secrets, not app-local conveniences, when protecting mobile access to cloud APIs.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.

👉 Read Guardsquare's analysis of why restricted Google API keys still fail in mobile apps

Context

Mobile API security fails when secrets are distributed into client code that attackers can inspect, extract, and reuse. In this case, the problem is not just disclosure of an API key, but the absence of a trustworthy control plane around request origin, app integrity, and downstream authorisation.

For IAM and NHI practitioners, the key lesson is that a mobile app bundle is not a secure secret store. If the API key authorises access to expensive or sensitive third-party services, the real control point has to move to the backend, where identity, attestation, and policy enforcement can be governed centrally.

Key questions

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. If the app must interact directly, use obfuscation, runtime hardening, and strict monitoring, but treat those as delay controls rather than true protection. Server-side authorisation remains the only durable boundary for high-value keys.

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. Package names, bundle IDs, and certificate hashes are not secret once the app is distributed. That means restrictions can filter some misuse, but they do not prove the caller is the original app instance.

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. Once exposed, it can be reused against the upstream API for quota abuse, billing abuse, or data access that appears legitimate to the provider. The control failure is assuming distribution does not equal disclosure.

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.

Technical breakdown

Why app restrictions are only a weak binding control

Google-style application restrictions bind an API key to metadata such as package name, bundle ID, and certificate hash. That sounds like identity binding, but the enforcement model is only as strong as the metadata an attacker can copy from the app bundle. Once those values are exposed, a spoofed request can present the same headers and look legitimate to the API endpoint. The result is not true authentication, only request filtering based on client-supplied claims. That is why restrictions can reduce casual misuse without stopping determined extraction and replay.

Practical implication: treat client-side restrictions as a friction layer, not a trust boundary, and move sensitive API access behind server-side enforcement.

Why obfuscation and RASP help, but do not solve secret exposure

Obfuscation makes automated scraping harder by hiding the key string, while runtime application self protection increases the cost of manual reverse engineering. Both are useful because most attackers follow the path of least resistance, but neither removes the secret from the distributed app. If the key remains in the bundle, a motivated actor can still recover it with enough effort. In identity terms, this is a lifecycle problem for the credential itself: once it is shipped to endpoints you do not control, revocation and containment become reactive rather than preventive.

Practical implication: use obfuscation and RASP to raise attacker cost, but do not rely on them as the primary control for high-value API credentials.

Why backend proxying changes the identity model

A backend proxy removes the API key from the public app and relocates trust to a server you control. That lets you authenticate the caller through existing user identity, or through app attestation when no user account exists. App attestation is especially important because it lets the server verify that the request came from an intact app instance rather than a repackaged binary or script. This is closer to genuine authorisation because the decision is made on server-verified evidence, not client-declared claims. It also gives teams a place to apply quotas, tiering, and policy based on business context.

Practical implication: place expensive or sensitive API calls behind a backend decision point that can verify user or app identity before issuing access.

Threat narrative

Attacker objective: The attacker wants to reuse someone else’s embedded API key to consume quota, trigger costs, or abuse privileged API access without paying for their own.

1. Entry occurs when an attacker extracts an API key from a mobile app bundle or from a spoofed request path that reuses exposed metadata.
2. Escalation happens when the attacker replays the key against the third-party API and the service cannot distinguish the request from the legitimate app.
3. Impact is quota exhaustion, unauthorised API usage, and potentially expensive downstream abuse of premium AI or cloud services.

NHI Mgmt Group analysis

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.

App attestation is a more durable control than app restriction because it reintroduces server-side trust evaluation. Restriction headers are client-declared claims, while attestation allows the backend to decide whether the app instance is genuine before granting a token. That distinction matters for mobile application security and for IAM teams extending policy into customer-facing apps. The control gap is not authentication alone, but whether the server can verify the identity of the caller context. Practitioners should design for server-verified evidence, not self-asserted metadata.

Backend proxying turns API key governance into a lifecycle and authorisation issue. Once the key sits only on the server, teams can enforce user tiers, rate limits, and revocation in one place. That aligns better with secrets governance and NHI management because the credential is no longer distributed beyond administrative control. The article also surfaces a named concept worth carrying forward: distributed-secret exposure, where a key embedded in client code is functionally public regardless of vendor restriction settings. Practitioners should govern the key as a server-side secret from the outset.

Mobile API abuse sits at the intersection of IAM, secrets management, and fraud economics. The attacker is not trying to compromise the app itself so much as to convert one user’s embedded trust into their own free usage. That means quota controls, billing controls, and identity verification all become part of the security model. For NHIMG, the broader lesson is that identity proof at the client edge must be paired with server-side enforcement or it will be bypassed. Practitioners should align mobile app security with secret lifecycle governance, not treat it as a standalone code-hardening problem.

What this signals

Distributed-secret exposure is the right way to think about mobile API keys that ship in client code. Once a secret is embedded in an app bundle, the governance question is no longer whether it is hard to find, but whether the backend can still verify who or what is using it. That shifts mobile security toward server-side identity assurance, a pattern that aligns well with the OWASP Non-Human Identity Top 10 and with OWASP Non-Human Identity Top 10.

The operational signal for programmes is clear: if expensive APIs are callable directly from a distributed client, then quota abuse and credential theft are both likely to outpace detection. Teams should move the trust boundary into a controlled backend, where identity, rate limiting, and revocation can be enforced together. That is where mobile app security intersects with identity governance rather than sitting outside it.

This also changes how practitioners should think about secret lifecycle controls. A key that can be recovered from the app bundle should be assumed exposed regardless of the vendor restriction model attached to it, so revocation, attestation, and server-side proxying become the controls that matter.

For practitioners

• 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. This gives you a single control point for authentication, authorisation, quota management, and revocation. It also prevents the key from being recoverable from the app bundle.
• Use app attestation for unauthenticated mobile experiences Where user accounts are not available, require attestation before the backend issues a token for API access. Validate that the request came from a legitimate app instance, not a repackaged binary or script, before allowing the proxy to forward the request.
• Apply obfuscation and RASP as delay controls Obfuscate embedded strings and use runtime application self protection to make scraping and reverse engineering more expensive. Treat these as attacker-friction measures only, because they slow extraction but do not remove the secret from the distributed client.
• Separate user entitlement from API entitlement If the mobile app already uses user accounts, authorise expensive or sensitive API usage through those accounts rather than through a shared client key. That lets you gate premium functions, apply per-user quotas, and revoke access without redeploying the app.

Key takeaways

• Mobile API keys shipped in app bundles are exposure-prone credentials, not durable trust anchors.
• Vendor application restrictions may slow casual abuse, but they do not stop spoofed requests or determined key extraction.
• Backend proxying with attestation gives teams a governable trust boundary that client-side controls cannot provide.

Key terms

• 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.
• 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.
• 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.
• Distributed-Secret Exposure: Distributed-secret exposure describes the condition where a credential embedded in client code becomes effectively public because the client can be inspected and copied. The secret may still function technically, but its security value is lost because possession is no longer limited to the intended application or user.

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

👉 Guardsquare's full post covers the spoofing path, obfuscation limits, and backend control options in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners connect secret lifecycle control to the broader identity programme.