Client-delivered secret exposure occurs when a credential is embedded in code or configuration sent to the browser. Because the browser is not a trusted boundary, the secret becomes recoverable by any user or attacker who can load the page and inspect the delivered artifact.
Expanded Definition
Client-delivered secret exposure is not just a coding mistake. It is a trust-boundary failure: a secret that should remain server-side is instead packaged into code, environment values, or configuration that reaches the browser.
The boundary matters because browser-delivered artifacts are inspectable by anyone who loads the page, including unauthenticated users, automated scanners, and attackers. Once a secret is present in client-side JavaScript, source maps, HTML, or embedded configuration, it is no longer a secret in the operational sense. The issue is broader than “visible in view source” because modern applications often ship bundled assets, build-time variables, and API wiring that can be unpacked even when the page itself looks normal.
This term is distinct from general secret management. Secret management covers storage, rotation, and access control across the lifecycle. Client-delivered secret exposure is specifically about disclosure through delivery mechanics. In practice, teams often misunderstand whether a token is “safe” because it is short-lived or scoped; scope limits damage, but they do not make a browser-delivered secret trustworthy.
For identity-sensitive systems, the boundary is especially important when the exposed value can be used to call downstream services, mint access, or identify internal endpoints.
Examples and Use Cases
Client-delivered secret exposure appears in everyday web delivery paths, especially when frontend and backend responsibilities are not clearly separated.
- A single-page app bundles an API key into JavaScript so it can call a third-party service directly from the browser.
- Build-time variables meant for server use are copied into a public frontend configuration file and shipped with the release.
- Source maps expose internal module names, endpoints, or embedded tokens that were thought to be hidden after bundling.
- A developer places a “temporary” access token in client code to avoid setting up a backend proxy, then it persists into production.
- A browser-visible configuration object reveals internal service URLs and credentialed request parameters that can be replayed or repurposed.
The common tradeoff is convenience versus containment. Direct client access can reduce latency and simplify integration, but it also moves trust to an environment the application does not control. Where browser delivery is unavoidable, teams usually redesign the interaction so the browser holds only a non-secret identifier, while the server performs the privileged action.
In security reviews, the practical question is often not “Is there a secret?” but “Could a hostile user recover something that grants access, attribution, or delegated capability?”
Security Implications
When a secret is delivered to the client, the confidentiality failure is immediate and durable. Any user who can fetch the page can often extract the value, and automated tooling can harvest it at scale across many sites. That turns a design oversight into a repeatable disclosure mechanism.
The downstream impact depends on what the exposed value can do. Some secrets enable direct API abuse, quota theft, or unauthorized data access. Others reveal internal service structure, tenant identifiers, or backend routes that make later attacks easier. Even if the secret is scoped, rotation alone may not reduce exposure fast enough if the application continues to ship the credential in each build.
A common practitioner observation is that teams treat frontend exposure as “less severe” when the token is low privilege or short-lived. In reality, the browser still becomes a public distribution channel, so the control failure is the delivery model, not only the privilege level.
For NHIMG readers, the important distinction is that exposed secrets often become an initial foothold for broader abuse of machine-to-machine calls, internal APIs, and delegated workflows.
Domain and Governance Relevance
In web application security, client-delivered secret exposure is a governance issue as much as a coding issue. It signals that build pipelines, frontend ownership, and backend control boundaries are not aligned around secret handling.
For non-human identity and automation-heavy environments, the term has sharper implications. Many exposed values are not human passwords but API keys, service tokens, webhook credentials, or signing material used by automated components. Once such a secret is shipped to the browser, it can be copied by anyone and reused outside the intended workflow, which undermines ownership, attribution, and revocation discipline.
This is also why the concept matters to identity governance. A secret that authenticates a machine or application should normally have a clear owner, lifecycle, and purpose limitation. Browser delivery breaks that control model because the credential is no longer bound to the trusted runtime that was supposed to hold it.
In practice, the term belongs to application security, but its governance consequences reach identity assurance, machine access control, and release engineering. The right question is whether the secret belongs in a trusted server-side boundary at all.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST IR 8596 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Browser-delivered secrets undermine access control by exposing credentials to untrusted users. |
| Recommendation: Secrets should not be exposed through delivery paths that bypass intended authentication and access boundaries. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 | The term directly concerns exposure of machine credentials and API secrets. |
| Recommendation: Machine credentials must remain out of client-delivered artifacts to preserve control over their use and revocation. | ||
| NIST IR 8596 | SC-4 | Secrets embedded in browser-delivered assets are shared with every recipient of the page or bundle. |
| Recommendation: Sensitive material in shared resources becomes accessible to all recipients, so delivery itself must be treated as disclosure. | ||
Risk and Threat Considerations
Client-delivered secret exposure creates an easy credential-extraction opportunity for attackers who can load the page or inspect bundled assets. The material risk is unauthorized reuse of a secret that was intended to authenticate a trusted backend or automated workflow.
Failure mechanism: The failure occurs when a secret is compiled, embedded, or referenced in code shipped to the browser, where it can be recovered from source, network traffic, bundles, or source maps. Attackers then replay the credential, call privileged APIs, or enumerate internal services without needing to compromise the server first.
Impact: The exposed value can enable API abuse, data access, quota theft, or misuse of delegated machine-to-machine capabilities. It can also weaken incident response because the organization must rotate the credential across every release artifact that contains it.
Practitioner Guidance
Teams often focus on whether the secret is low privilege instead of asking whether it is publicly recoverable. If a browser can receive it, attackers can usually extract it too.
- Review frontend bundles, source maps, and runtime configuration for any value that authenticates to a backend, partner API, or automation endpoint.
- Replace direct browser use of privileged secrets with a server-side token exchange or proxy so the client only receives a non-secret reference.
- Classify every client-visible credential by owner, purpose, and rotation path, then remove any item that cannot be rotated quickly and independently.
- Add release gating that blocks deployment when build outputs contain known secret patterns or environment variables intended for server-side use.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 4, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
