What breaks when a public client is used to store API keys?

Why public clients break secret storage

A public client is readable by the person using it, which means any secret embedded in that client is not really secret. Once an API key ships into browser code, a mobile bundle, a desktop app, or another inspectable runtime, it can be copied, replayed, and redistributed. The design error is not “weak protection,” it is choosing a storage location that cannot preserve confidentiality.

That matters because API keys are bearer credentials. If the client can be inspected, the key should be treated as exposed by design, not merely at risk after a breach. A server-side component can still hold credentials safely because users do not receive the executable image, source, environment, or process memory that contains them.

What fails operationally after the key is exposed

Once a public client contains the key, rotation stops being a controlled maintenance action and becomes an incident response exercise. You no longer know who copied the value, where it was cached, or whether old versions still exist in app stores, package registries, screenshots, logs, or browser storage.

That is why teams lose confidence in revocation timing, scope, and audit trails. Even if the exposed key is rotated, the old one may already have been reused in automation or shared by users. For safer key lifecycle handling, NHIMG’s API Key Management Guide is the right place to anchor the rotate, revoke, and scope decisions.

In practice, public-client exposure also collapses attribution. A leaked key no longer tells you whether a call came from your app, a reverse-engineered copy, or a hostile script. That makes quota enforcement, anomaly detection, and abuse investigation far less reliable.

How to redesign the trust boundary

The fix is to move the credential to a component the user cannot inspect, then let the public client call that component instead of the upstream API directly. In a browser or mobile scenario, that usually means a backend-for-frontend, token broker, or server-side proxy that enforces policy before forwarding requests.

When the secret belongs to a non-human workload rather than an end user, the credential should be treated as a workload identity problem, not a client distribution problem. NHIMG’s Ultimate Guide to NHIs is a useful parent concept for that boundary, and NHI Authentication Guide helps when the design needs a stronger machine-authentication pattern than a static shared key.

If the client must still call an upstream service directly, the safer alternative is to replace the embedded secret with short-lived, audience-scoped tokens issued through a controlled flow. The point is to make the client hold something limited and revocable, not a reusable secret that unlocks everything.

Risk and Threat Considerations

Public clients make secret theft cheap because the attacker does not need privileged access, just access to the distributed artifact. Reverse engineering, traffic inspection, source viewing, and package extraction are enough to recover the value. Once recovered, the same key can be reused at scale until detection or revocation closes the window.

Failure mechanism: The design places a bearer secret in an inspectable artifact, so confidentiality depends on hiding something the user already receives. That creates predictable extraction, replay, and uncontrolled reuse.

Impact: API abuse can follow immediately, including quota exhaustion, unauthorized data access, fraudulent requests, and loss of trust in every system that relies on that key. For threat modelling of API abuse patterns, OWASP API Security Top 10 is the clearest external reference point.

Practitioner Guidance

What to verify: Check whether the API key is embedded in a public artifact, configuration shipped to users, or client-side environment that can be inspected. If yes, treat it as exposed and plan for replacement rather than preservation.

Decision rule: If the credential must survive in an environment the user can inspect, it is the wrong credential. Use a server-held secret, then expose only a limited token or mediated request path to the public client.

Common mistake: Teams often assume obfuscation, minification, or app-store distribution makes a key “good enough.” It does not, because the control problem is not discovery prevention, it is secret containment.

Practitioner takeaway: The design choice is binary: if users can inspect the runtime, they can usually extract the secret, so protect the upstream credential by removing it from the public client entirely.

Related resources from NHI Mgmt Group

• What breaks when API keys are used as the main MCP credential?
• What breaks when API keys are used for service-to-service access at scale?
• What breaks when provider API keys are stored directly in application code instead of a controlled gateway or secret store?
• What breaks when organisations do not track where machine tokens and API keys are used?