What should developers change first when client-side secrets are discovered?

Why client-side secrets should be treated as a design flaw, not just a leak

Client-side secrets are problematic because anything shipped to a browser, mobile app, desktop client, or other untrusted environment can usually be extracted, replayed, or reused. The immediate response is containment, but the larger issue is trust design: if the application still relies on a secret that the client can hold, the attacker and the legitimate user have the same material. OWASP’s Non-Human Identity Top 10 is useful here because it frames secrets as identities and credentials that must be governed across their lifecycle, not embedded as convenience shortcuts. In practice, many security teams discover the real exposure only after the first secret has already been copied from a build artifact, debug log, or shipped bundle.

What changes first after discovery, and what has to change next

The first change is always to stop the exposed secret from remaining valid. That means revoking it, rotating any dependent credentials, and confirming that replacement values are not delivered through the same weak path. Until that happens, every other improvement is secondary because the attacker and the client still share access. Once the immediate exposure is contained, the development team should remove the dependency on client-held trust altogether.

That redesign usually means moving from static embedded material to server-issued, short-lived credentials, or to an interaction model where the client proves something about itself without becoming the trust anchor. In some products that can be done with ephemeral tokens, proof-of-possession approaches, attestation checks, or backend mediation. The right choice depends on whether the secret was authorising a user action, identifying an application instance, or unlocking an integration. The security goal is not to hide the secret better in the client, because obfuscation only raises the extraction cost slightly. The goal is to ensure a copied value has limited lifetime, limited scope, and limited value outside the intended session. NIST SP 800-53 Rev. 5 helps here because it treats access control, identification, authentication, and system integrity as managed controls rather than one-off implementation details. If the replacement design still lets a copied secret be used without meaningful expiry, binding, or validation, the change is cosmetic, not corrective.

• Prioritise removal of hard-coded secrets from source, bundles, and mobile packages before any new release ships.
• Validate whether the secret is being used for authentication, authorisation, API access, or software integrity, because the replacement pattern differs by use case.
• Prefer short-lived, server-mediated credentials where the client only receives the minimum needed for the current session or transaction.
• Check whether downstream systems still trust the old credential chain, including caches, partner integrations, and automation jobs.

Where this guidance breaks down is when the client is operating in a truly hostile environment and the product design still assumes secrecy as the primary control; at that point, the architecture itself has to change, not just the secret value.

Where teams get tripped up after rotation and how to tell the redesign is real

Tighter secret handling often increases development and operational overhead, requiring teams to balance faster client integration against weaker trust assumptions. The common mistake is treating rotation as the finish line when it only removes the most immediate exposure. Another trap is replacing one static secret with another static secret that is simply stored in a different place, such as a configuration service, local cache, or signed package. That may improve hygiene, but it does not change the trust model.

Teams should also be careful not to over-apply protections that do not address the actual weakness. For example, encrypting a client-side secret at rest can be useful for reducing casual disclosure, but it does not solve extraction from a running client or a debugged binary. A more meaningful signal of progress is whether the application can continue functioning when the original secret is revoked and whether client compromise now has a bounded impact. If a stolen value can still be replayed broadly, or if the application fails closed only after the attacker has already succeeded, the redesign is incomplete. The point is to make extracted material disposable, not merely harder to read. The guidance is strongest when the secret represented machine access or application trust, and it is less direct when the “secret” was actually a user-controlled preference or a low-impact configuration token.

Practitioner Guidance: The first decision is whether the exposed material can be invalidated immediately without breaking essential service, because that determines how quickly containment can be separated from redesign.

Practitioner Guidance: What teams should verify is that the new design no longer treats the client as a trustworthy vault. If a copied value still authorises meaningful action after rotation, the underlying exposure remains.

Practitioner takeaway: Rotation removes the symptom, but only redesign removes the assumption that made the secret dangerous in the first place.

Related resources from NHI Mgmt Group

• Who is accountable when exposed secrets or client-side fraud leads to losses?
• Why do client-side secrets create a bigger risk than source-code secrets alone?
• How do identity and secrets risks change when developers use code generation?
• How do runtime protections change the security value of client-side code?