Client-delivered code turns secret handling into an exposure problem

At a glance

What this is: This analysis shows that secrets embedded in browser-delivered code, source maps, or config responses are effectively public to anyone who loads the page.

Why it matters: It matters to IAM, PAM, and application security teams because client-side secret exposure creates an access and governance problem that traditional backend-focused review often misses.

By the numbers:

• FireCompass’s assessment surfaced 12 candidate secret and API-key exposure findings across 10 distinct programs.

👉 Read FireCompass’s analysis of secret and API-key exposure in browser-delivered code

Context

Client-side secret exposure is a governance failure, not just a coding mistake. If a credential is sent to the browser, it is no longer protected by server-side assumptions, because the user can inspect bundles, source maps, runtime objects, and config responses.

This article focuses on the boundary between what should remain server-side and what the browser can always see. That boundary matters to identity teams because the exposed material often includes API keys, signing secrets, and internal application credentials, which are all forms of non-human identity control in practice.

Key questions

Q: What breaks when a signing secret is shipped to browser-delivered code?

A: The authentication boundary breaks, because the browser is no longer a safe place to keep a secret that signs tokens or requests. Anyone who loads the page can recover the key and mint valid credentials or signed calls until the secret is rotated. That turns a normal client asset into reusable trust material.

Q: Why do exposed API keys and signing secrets create different levels of risk?

A: An exposed API key may mainly allow quota abuse or limited third-party access, while a signing secret can let an attacker forge identities and generate new valid requests. The second case is more serious because it compromises trust itself, not just one captured token or one service account instance.

Q: How should security teams decide what can safely be shipped to the browser?

A: Only information that can be treated as public should ever reach the browser. If a value authenticates a backend, authorises internal access, signs requests, or unlocks non-public data, it belongs on the server or behind a proxy. Treat build artifacts, config responses, and source maps as release controls, not afterthoughts.

Q: How do teams know whether a secret exposure is operationally exploitable?

A: They should validate whether the recovered value is live, accepted by the target system, and capable of producing a bounded real-world effect. If a single authenticated request, token mint, or billable call succeeds, the exposure is operational, even if the final report later classifies it as informative.

Technical breakdown

Why browser-delivered code makes secrets effectively public

Anything shipped to the browser is visible to the user, even if it is minified or hidden from the interface. JavaScript bundles, source maps, global window objects, and config responses are all retrievable client artifacts. If a secret is embedded in any of them, the secrecy boundary has already failed because the browser is not a trusted execution boundary for server credentials. The problem is structural: the application has decided to distribute a credential to every client that can load the page.

Practical implication: keep server-to-server secrets out of client-delivered assets and review build pipelines for accidental secret embedding.

Why signing secrets are more dangerous than exposed API keys

A third-party API key may only enable quota consumption or limited data access, but a signing secret lets an attacker mint fresh authenticated requests. That changes the issue from leaked access to forged identity, because the attacker is no longer replaying one captured token. They can create unlimited valid tokens or signed messages until the secret is rotated. In identity terms, the credential has become a reusable trust primitive for the target system, which is why these exposures are more severe than many teams assume.

Practical implication: prioritise signing-secret exposure above ordinary API-key leakage because it can collapse authentication, not just reveal usage capacity.

How controlled validation separates signal from a key-shaped string

A static scanner can identify something that looks like a secret, but it cannot prove live reachability or impact. The validation model described in the article uses three steps: detect the candidate, confirm the secret is live by making a real request, and then perform one bounded action to prove consequence without causing collateral damage. That matters because remediation should be based on demonstrated exposure, not just string patterns. It also gives defenders a repeatable way to distinguish stale values from credentials that can actually be abused.

Practical implication: build validation and revocation workflows around confirmed live credentials, not around pattern-matching alerts alone.

Threat narrative

Attacker objective: The attacker wants to turn client-delivered code into reusable authentication material for data access, event forgery, or quota abuse.

1. Entry occurs when a secret is embedded in a JavaScript bundle, source map, global object, or config response and delivered to every browser that loads the page.
2. Escalation follows when the recovered value is used to authenticate against the live backend or third-party API, proving that the secret is active and accepted.
3. Impact occurs when the attacker can consume quota, enumerate data, mint forged tokens, or inject authenticated requests without any backend breach.

NHI Mgmt Group analysis

Client-delivered secret exposure is a non-human identity governance failure. When a signing secret or internal credential is shipped to the browser, the issue is not merely leakage but uncontrolled delegation to an untrusted execution environment. That makes the exposed value a non-human identity that has escaped its intended lifecycle boundary. IAM and application teams should treat browser-delivered secrets as a governance defect, not a post-release nuisance.

Signing-secret exposure is the named concept that matters most here: auth-forgery by distribution. Unlike a simple API key leak, a signing secret allows a remote party to become a trusted caller by minting new requests or tokens. That creates a durable identity compromise because the system cannot distinguish legitimate issuance from attacker-generated use. Practitioners should design controls that prevent signing material from ever entering client assets.

The validated versus informative split is a policy signal, not a reassurance. Some programs classify exposed keys as informative because of quota scope or limited downstream impact, but the exposure mechanism is still real. The control question is whether the secret can be reached, reused, or rotated before abuse, not how the report was eventually triaged. Teams should align severity with exploitation potential, not with reporting convenience.

Source maps and config endpoints are now first-class secret-discovery surfaces. The article shows that risk is not confined to obvious hardcoded values in source bundles. Build outputs, debug artifacts, and runtime configuration responses all expand the attack surface for secret harvesting. Security reviews should therefore include release artifacts, not just application code, when judging whether a credential is client-visible.

What this signals

Secret exposure is increasingly a build-and-release governance issue, not a late-stage application bug. As frontend toolchains, source maps, and runtime config become richer, the number of places a credential can leak grows faster than traditional code review can reliably inspect. Teams should shift release assurance toward artifact scanning, credential classification, and automatic rotation triggers before exposure becomes routine.

Client-side secrets now create identity drift between who a system thinks is calling and who actually is. That drift is especially relevant to NHI governance because a leaked signing secret can manufacture apparently valid non-human callers at scale. The practical response is to pair secret prevention with identity lifecycle controls, and to link confirmed exposure to rapid revocation using the Guide to the Secret Sprawl Challenge.

The broader lesson is that every browser-exposed credential should be treated as an access design decision. If a secret must exist to support a public page, it should be scoped to the smallest possible privilege, monitored for abuse, and replaced with short-lived server mediation wherever feasible.

For practitioners

• Ban server-side secrets from client artifacts Reject releases that contain signing keys, internal application secrets, or server-to-server tokens in JavaScript bundles, source maps, or config responses. Make this a release-blocking control in CI and review build outputs, not just source code.
• Scope every browser-exposed API key tightly Apply referrer, IP, quota, and usage restrictions to any third-party key that must ship client-side. If the key can be used outside the intended frontend or published content, it is over-scoped and should be replaced.
• Treat confirmed exposure as compromise until rotation completes Once a live secret is confirmed in client-delivered code, rotate it immediately and verify downstream revocation. Do not wait for final report closure if the credential is capable of authentication or request signing.
• Remove or gate production source maps Disable public source maps in production, or serve them only behind authentication with strict access logging. Source maps can expose full frontend source and embedded credentials even when the visible bundle is minified.

Key takeaways

• Secrets embedded in browser-delivered code are effectively public, because the user can inspect everything the browser receives.
• Signing secrets are more dangerous than ordinary API keys because they let an attacker forge trusted requests, not just consume quota.
• Confirmed client-side secret exposure should trigger immediate rotation, source-map control, and tighter release governance.

Key terms

• Signing Secret: A signing secret is a credential used to create valid authentication artifacts such as JWTs, HMAC signatures, or signed requests. If it is exposed, an attacker can generate new trusted messages rather than merely replaying one captured token, which makes the exposure materially more serious than many API-key leaks.
• Source Map: A source map is a file that links minified production JavaScript back to the original readable source code. It preserves developer-friendly names, structure, and comments for debugging, but if exposed publicly it can disclose implementation details that attackers can use for reconnaissance.
• Client-Delivered Secret Exposure: 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.
• Controlled Exploitation: Controlled exploitation is the practice of proving a secret is live and impactful with one bounded action, then stopping. It turns a detection into an evidence-backed finding without causing quota exhaustion, data destruction, or lasting side effects, which makes remediation decisions clearer and safer.

What's in the full report

FireCompass’s full analysis covers the operational detail this post intentionally leaves for the source:

• Representative mechanics for each exposure pattern, including how the secret appeared in bundles, source maps, or config responses.
• The detect, validate, controlled-exploit sequence used to prove whether each candidate secret was live and usable.
• Severity and disposition context for the seven validated findings versus the five closed informative reports.
• How FireCompass grouped the findings into recurring mechanisms across different industry programs.

👉 The full FireCompass article covers the exposure patterns, validation model, and remediation lessons in more depth.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to turn identity controls into operational release discipline.