How should security teams handle secrets in frontend applications?

Why frontend apps are the wrong place for secrets

A frontend bundle is distributed to browsers, so anything embedded in it should be treated as public. That includes API keys, shared tokens, credentials in config files, and endpoints that depend on hidden trust. The real design question is not how to hide the secret better, but how to remove the need for the browser to hold it at all.

This is why teams should shift privileged actions to server-side components, particularly a backend-for-frontend pattern that can mediate requests, enforce policy, and keep sensitive authentication material out of shipped code. The same logic applies to build-time variables, source maps, and other places where developers often assume a value is private when it is only inconvenient to inspect.

For a broader treatment of the secrets problem, NHIMG’s Secrets Management Guide explains why centralising secrets, reducing exposure paths, and moving toward secretless patterns matter once a secret no longer belongs in client code.

Teams also need to separate “secret” from “identifier”. A public publishable key or client identifier may be acceptable in frontend code if it is designed for that exposure, but it must not be confused with a credential that can authorise privileged actions. The safest test is simple: if a value would cause harm when copied by an attacker, it does not belong in the browser.

What a safer frontend architecture looks like

The preferred pattern is to let the frontend authenticate the user, then let a server-side layer handle privileged API calls using server-held credentials or short-lived delegated credentials. That keeps the browser focused on user interaction, while the server owns the trust boundary, rate limiting, and secret handling.

When teams need guidance on credential form factor, NHIMG’s Ultimate Guide to NHIs, Static vs Dynamic Secrets is useful for understanding why static credentials create long-lived exposure, while dynamic or short-lived credentials reduce blast radius.

If a frontend must call an upstream service directly, the question becomes whether that service can be reached with a non-secret mechanism such as a user session, delegated token exchange, or a narrowly scoped public flow. If the answer is no, the call belongs behind a trusted backend. Do not compensate by obfuscating the secret, because obfuscation only slows discovery and does not change exposure.

For API-centric teams, the safest references are the runtime controls around issuance, scope, revocation, and rotation. NHIMG’s API Key Management Guide is the right destination when you need to understand how to handle exposed keys, but the better architectural decision is still to avoid distributing keys to the client in the first place.

How to verify the fix and keep secrets from reappearing

Once the architecture changes, teams should verify the exposure path rather than trusting code review alone. Search the frontend repository, build artefacts, source maps, CI variables, and CDN output for credentials and token-like strings, then confirm that any remaining client-side values are intentionally public and low risk.

For implementation discipline, NHIMG’s Guide to the Secret Sprawl Challenge helps teams recognise how credentials leak into code, pipelines, and supporting files, which is exactly the failure mode that makes frontend secret handling so dangerous.

Rotation still matters after remediation. Any secret that may have been shipped to browsers, logged in telemetry, or exposed in a public bundle should be treated as compromised and replaced, even if there is no evidence of abuse. In parallel, move to short-lived sessions and scoped backend credentials so that a leak does not create a durable reuse path.

External references can help teams align the implementation with broader practice. The OWASP Cheat Sheet Series is a useful implementation resource for secure session handling, authentication, and secret-handling patterns, while OWASP Non-Human Identity Top 10 is relevant when the browser problem is really part of a broader machine-credential and secret lifecycle issue.

Risk and Threat Considerations

Frontend secrets are exposed by design, which makes them attractive to attackers who scrape bundles, inspect network traffic, or mine public repositories and build artefacts for credentials. The main risk is not just initial disclosure, but the follow-on abuse of API access, backend operations, and third-party services that trust the leaked material.

Failure mechanism: A secret copied into client code loses the protection of server-side storage and becomes recoverable by anyone who can view the shipped application, inspect build output, or reuse exposed tokens before they are rotated.

Impact: The likely consequences are unauthorised API use, data exposure, account or service abuse, quota exhaustion, and a wider incident response burden because the same secret may have been reused across multiple environments or integrations.

Practitioner Guidance

What to prioritise: Remove privileged browser-held secrets first, then assess whether any remaining client-side value is truly non-sensitive. If a value can authorise write access, administrative actions, or cross-environment access, treat it as a credential problem, not a frontend optimisation problem.

What to verify: Confirm that the browser only receives values that are safe to expose, that the server-side layer owns privileged calls, and that secrets are stored, rotated, and revoked outside the frontend release cycle. The control is working only when the client bundle can be rebuilt without any hidden dependency on a private token.

Common mistake: Teams often keep the secret in the frontend and add obfuscation, proxy rules, or “restricted” keys as a compensating control. That may reduce casual misuse, but it does not remove the exposure, so it should never be treated as equivalent to proper server-side handling.

Practitioner takeaway: The correct standard is not “hide the secret better in the browser”, it is “design the frontend so it never needs a secret that would matter if copied.”

Related resources from NHI Mgmt Group

• How should security teams handle cloud secrets that are shared across applications and pipelines?
• How should security teams handle SSH keys and app secrets when deploying containerized applications with Kamal?
• How should security teams handle leaked secrets across developer workflows?
• How should security teams handle exposed secrets in modern software pipelines?