If a credential needs rotation, revocation, or audit trails, it belongs in a secrets manager rather than in code or environment variables embedded in a client build. A good test is whether exposing that credential would create financial, administrative, or data-access impact. If yes, production handling should be server-side and centrally managed.
When a secret has outgrown the frontend
The practical line is not “is it hidden” but “does this credential need server-side control.” Once a value needs rotation, revocation, expiry, auditability, or scoped access decisions, it should leave the frontend and live in a central secret store. That is also true when secrets management best practices point toward centralised handling rather than embedding sensitive material in code or client builds.
A frontend can only ever protect a value by obscurity. A secrets manager changes the control model: the secret can be issued, replaced, inspected, and removed without shipping a new client artifact. If the secret is operationally meaningful enough that losing it would force an incident response decision, the frontend is already the wrong trust boundary.
What makes a secret a backend responsibility
The strongest indicator is lifecycle, not sensitivity alone. If a secret must be rotated regularly, revoked immediately after compromise, or tied to an inventory and audit trail, it has become part of operational security. That is especially clear for API keys and tokens, where API key lifecycle management depends on being able to change or disable the credential without touching the frontend.
Another signal is blast radius. A frontend-exposed credential is effectively copied into every delivered client and can be extracted from bundles, memory, logs, browser tools, or source control. A secret manager is appropriate when the team needs one place to enforce who can retrieve the secret, when it expires, and whether it should be replaced with a short-lived alternative.
Teams should also treat secrets that enable data access, administrative actions, or money-moving actions as backend material even if the app is “just” a client app. The question is whether the credential creates meaningful consequence if used out of context. If yes, it needs server-side custody and governed retrieval, not distribution to every user device.
Designing the decision around exposure and replacement
The decision is usually easier if teams separate “configuration” from “credential.” A frontend may contain public settings, endpoints, and non-sensitive identifiers, but not material that authenticates a caller or unlocks privileged operations. When the credential cannot be safely removed from the client without breaking function, the deeper fix is usually architectural, such as moving the call server-side or exchanging the static secret for a scoped, short-lived token.
That is why secret managers matter most when they support replacement. The right pattern is not just storage, but a path to rotation, revocation, environment separation, and traceability. For teams evaluating tools and operating models, the Secrets Management Buyer’s Guide is useful because it frames the choice around capabilities that actually matter in production: central control, vendor fit, and practical enforcement.
When a secret is still visible in a frontend, assume it is already compromised from a governance perspective, even if no abuse has been detected. That is why a good threshold is simple: if you would need to ask who used the secret, from where, and whether it should be replaced, then it belongs in a managed backend path.
Risk and Threat Considerations
Frontend-held secrets tend to fail by replication. Every shipped client becomes a copy point, and copies are difficult to recall once they are embedded in code, bundles, or distributed assets. Attackers prefer these secrets because they are easy to extract at scale and often remain valid long after the team believes they were “hidden.”
Failure mechanism: the credential is exposed to anyone who can inspect the client, then reused outside the intended trust boundary, with no reliable way to rotate, revoke, or audit each copy.
Impact: the result can be unauthorized API access, privilege misuse, data exposure, or fraudulent actions that are hard to contain because the same secret may exist in many distributed copies.
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 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Frontend-embedded secrets are exposed to client-side extraction and leakage. |
| NHI-07 — Long-Lived Secrets | Secrets that need rotation or revocation should not remain static in distributed clients. | |
| NHI-05 — Overprivileged NHI | A client-held secret often grants broader access than the frontend should need. | |
| Recommendation — Remove secrets from client builds and centralise retrieval in a managed backend path. Replace long-lived frontend secrets with short-lived or server-side managed credentials. Scope credentials to the minimum access needed and eliminate direct frontend privilege. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The issue hinges on lifecycle control for authenticators, including rotation and revocation. |
| AC-6 — Least Privilege | Frontend secrets should not carry unnecessary privilege beyond the client use case. | |
| Recommendation — Manage secret lifecycle centrally and rotate or revoke authenticators promptly. Limit each secret to the smallest access scope required for the workload. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Secrets managers typically protect credentials through controlled storage and handling. |
| Recommendation — Protect sensitive credentials with controlled storage and secure handling mechanisms. | ||
Practitioner Guidance
What to verify: ask whether the credential can be revoked without breaking legitimate users, whether it has a known owner, and whether you can prove when it was last rotated. If any of those answers are unclear, treat the value as a managed secret rather than a frontend constant.
Decision rule: if the secret grants access to production data, administrative functions, or paid services, remove it from the frontend and replace the pattern with server-side retrieval or a short-lived token flow. If the value is truly non-sensitive, keep it public by design and stop calling it a secret.
Practitioner takeaway: the move to a secrets manager is justified when the team needs control over the secret’s lifecycle and blast radius, not merely when the value feels sensitive.