How should security teams handle secrets in frontend applications?

Why This Matters for Security Teams

Frontend secrets are not secrets once they ship to a browser. Any token, API key, certificate, or embedded credential can be inspected, copied, replayed, or automated at scale. That is why the correct pattern is to treat the browser as an untrusted execution environment and move privileged actions behind a server-side boundary such as a BFF, with secrets stored and rotated centrally. The practical risk is not only theft, but persistence: GitGuardian found that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which is exactly why detection without revocation fails. See the Guide to the Secret Sprawl Challenge and the OWASP Non-Human Identity Top 10 for the broader exposure model.

Security teams also get tripped up by duplicated placement. Entro Security reported that 62% of all secrets are duplicated and stored in multiple locations, while 44% of NHI tokens are exposed in the wild through tickets, chat, code, and documentation. That means frontend leakage is rarely an isolated mistake; it is often one symptom of weak secret lifecycle control across development, CI/CD, and release processes. In practice, many security teams encounter frontend secret exposure only after abuse has already occurred, rather than through intentional review.

How It Works in Practice

The safest operating model is simple: the frontend should authenticate the user or session, but it should not hold privileged credentials of its own. Instead, the browser calls a backend-for-frontend service, and that service performs downstream API calls using server-side credentials that are kept in a secrets manager and rotated automatically. This reduces blast radius and makes revocation possible when a credential is exposed. The implementation goal is not to make secrets hidden in the browser harder to find; it is to remove them from the browser entirely.

In mature environments, this usually means three control layers working together. First, use short-lived session tokens for the browser, not long-lived API keys. Second, issue downstream credentials just in time, with expiry aligned to the task or session. Third, scope each backend credential to one workload or narrow purpose so compromise does not unlock unrelated systems. Current guidance suggests pairing this with policy checks at request time, especially where a frontend can trigger sensitive operations indirectly. The Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack show how quickly exposed credentials become reusable outside the original app boundary.

• Keep browser code free of API keys, service account material, and static tokens.
• Put privileged API calls behind a BFF or server-side proxy that owns secrets.
• Store credentials in a secrets manager with rotation, expiry, and revocation.
• Use least-privilege service accounts and separate credentials per environment.
• Log secret access and downstream API use so anomalous reuse is visible.

This guidance breaks down in legacy single-page apps that directly call third-party APIs without a backend mediation layer because there is no server boundary to absorb the credential.

Common Variations and Edge Cases

Tighter secret handling often increases engineering overhead, requiring organisations to balance delivery speed against stronger isolation and rotation. That tradeoff is real, especially when product teams want fast client-side integrations or when public APIs seem harmless. Best practice is evolving, but there is no universal standard that says a browser may safely hold a privileged secret simply because the key is “low risk.” If the credential can be copied, it is a secret only in name.

Some teams try to use obfuscation, split keys, or environment-variable injection in build pipelines. Those measures can reduce casual exposure, but they do not change the trust model. A motivated attacker can still inspect bundle content, intercept network calls, or extract runtime values. For that reason, NHI governance should focus on secret minimisation, short TTLs, and revocation pathways rather than disguising credentials in shipped code. The Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful for understanding why dynamic secrets are preferred where application design allows it, and the OWASP Non-Human Identity Top 10 remains the clearest baseline for reducing standing credential exposure.

Edge cases usually appear in public frontend products, offline-capable clients, and integrations with third-party SDKs. In those cases, teams should look for token exchange patterns, signed requests, or delegated auth flows that preserve user access without embedding service secrets. When no such pattern exists, the safest answer is still to remove the privilege from the browser and force the operation through a server-controlled trust boundary.

Related resources from NHI Mgmt Group

• How should security teams handle secrets in AI-generated code?
• How should security teams protect HMAC secrets in production systems?
• How should security teams decide whether JIT access is safe for non-human identities?
• How should teams reduce the risk from exposed NHI secrets?