TL;DR: 12 candidate secret and API-key exposures surfaced across 10 bug bounty programs, with 7 validated by affected programs and 5 closed as informative, according to FireCompass, showing that browser-delivered code can expose signing secrets, internal credentials, and third-party API keys before any backend breach occurs. The real control gap is not detection but deciding what must never be shipped client-side, how it is scoped, and how quickly confirmed exposure is revoked.
At a glance
What this is: This analysis shows that secrets embedded in browser-delivered code become retrievable the moment the page loads, making exposed API keys and signing secrets a client-side trust problem rather than a backend breach problem.
Why it matters: IAM, app security, and NHI teams need to treat anything shipped to the browser as publicly readable, because privilege scope, token lifecycle, and revocation speed now determine whether an exposure stays contained.
Context
Client-delivered code creates an access boundary that many engineering teams still misjudge. If a secret, token, or signing key reaches the browser, it is no longer protected by server-side assumptions, which makes frontend build review part of identity and credential governance, not just application delivery.
The article's central issue is the control gap between what is rendered for a user and what is still intended to remain private. That matters to NHI governance because API keys, signing secrets, and service credentials are all non-human identities or identity-like artefacts once they are usable outside their intended trust boundary.
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 teams decide whether a client-side secret exposure is a real incident?
A: Treat it as real once the recovered value is live and can be used in the intended workflow, even if the original finding came from pattern matching. If the secret still authenticates or authorises a bounded action, it is not theoretical. Classification labels can follow, but containment and rotation should come first.
Q: When should organisations rotate a secret found in frontend code?
A: Rotate immediately after confirmation, not after a full postmortem. A credential embedded in shipped code is already exposed to anyone who loads the page, so waiting for routine change windows extends the blast radius unnecessarily. If the value authorises production access, revocation should be treated as urgent lifecycle hygiene.
Technical breakdown
Why browser-delivered code turns secrets into public artefacts
Anything sent to a browser must be treated as readable by the recipient. Minified JavaScript, source maps, global window objects, and config responses all cross the trust boundary intact, even if the UI never renders the value. That means the security question is not whether a secret was visible on screen, but whether it was ever packaged for client delivery. Once a credential is embedded in shipped code, attacker effort drops from exploitation to inspection.
Practical implication: move all server-to-server secrets and signing material out of client-delivered assets before release.
Why third-party API keys and signing secrets fail in different ways
A third-party API key and a signing secret are both credentials, but their blast radius differs. A restricted maps key may leak quota or billing, while a signing secret can mint valid tokens, bypass authentication, or forge internal requests. That is why the same distribution mistake can look low impact in one program and critical in another. The real risk is not the secret type alone, but whether the exposed value authorises identity, data access, or transaction integrity.
Practical implication: classify exposed secrets by what they can authorise, not just by which service issued them.
Why proof of live use matters more than pattern matching
Secret scanners can identify key-shaped strings, but they cannot prove whether a recovered value is live, scoped, or already revoked. The more reliable test is whether the secret authenticates against the intended backend and whether a single bounded action demonstrates real impact. That validation step separates noise from evidence and helps teams understand whether they are dealing with a stale value, a test token, or an operational credential still trusted by production systems.
Practical implication: require live validation and immediate revocation workflows for any confirmed secret exposure.
Threat narrative
Attacker objective: The attacker wants to reuse browser-delivered credentials to authenticate as a trusted caller, forge valid requests, or consume services with the victim's authority.
- Entry occurs when a secret, signing key, or internal credential is embedded in a JavaScript bundle, source map, or configuration response that is delivered to every browser session.
- Credential access follows when an observer uses developer tools, a source map, or bundle inspection to recover the value without breaching a backend system.
- Escalation occurs when the exposed credential authorises API calls, signed requests, or token minting outside the intended caller boundary.
- Impact is the ability to enumerate data, forge requests, or consume third-party quota using a credential the issuing team assumed would remain server-side.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Client-delivered secrets are an identity governance failure, not just a code quality defect. If a credential can authenticate a caller, then it has an identity lifecycle, even if engineering teams treat it as a build-time convenience. The browser boundary does not dilute that risk, it exposes it. Practitioners should treat frontend distribution as part of secret governance, with the same ownership, scope, and revocation discipline they apply to backend credentials.
Client-side exposure collapses the usual distinction between retrieval and compromise. In traditional backend incidents, defenders have time to detect, investigate, and scope misuse. When the secret is shipped to the client, the compromise exists the moment the page loads, which means the governance question moves upstream to release engineering and entitlement design. The practitioner conclusion is simple: if a secret must stay private, it must never cross the browser boundary.
Secret type determines blast radius, but not the control failure. A maps key may primarily create billing and quota risk, while a signing secret can undermine authentication itself. The common failure is assuming that a secret is safe because it is not displayed in the UI. That assumption no longer holds for modern web apps, SPAs, and agent-assisted frontends, so teams need stronger release gates for anything that can authorise calls or mint trust.
Browser-delivered code creates a client trust gap that security programmes often under-model. That gap exists when teams trust the browser to receive information but do not treat the delivered payload as observable by the recipient. The concept matters across IAM, PAM, and NHI work because every exposed token, key, or signing secret is a non-human identity artefact with an ownership and revocation problem. Practitioners should close the gap by preventing sensitive identity material from reaching the client in the first place.
Validated exposure should trigger immediate lifecycle action, not classification debate. Whether a program labels a report informative, duplicate, or triaged does not change the fact that a live credential was reachable in shipped code. Identity teams should align revocation thresholds with exposure confirmation, not with severity labels alone. The practitioner conclusion is that confirmed client-side secrets belong in emergency rotation and scoping reviews, not queued for routine remediation.
From our research library:
- DeepSeek alone generated 113,000 new exposed API keys in 2025, illustrating how new AI providers create credential exposure before security guardrails catch up, according to the State of Secrets Sprawl 2026.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Client-delivered secrets are now a release-governance issue. Teams that still rely on frontend obfuscation are assuming the browser is a trusted container, which it is not. The practical shift is to block sensitive identity material before build artefacts are published, not after extraction by a scanner or researcher.
Browser-exposed credentials widen the NHI attack surface. A leaked token, signing key, or over-scoped API key is still a non-human identity control failure, even when it appears inside application code rather than a vault. Ultimate Guide to NHIs research shows only 20% have formal processes for offboarding and revoking API keys, which means many teams are unprepared to respond quickly enough once exposure is confirmed.
Client trust gap: the category to watch is any system that assumes “not shown in the UI” equals “not accessible to the client.” That assumption is fragile across SPAs, source maps, agent-assisted frontends, and config endpoints. Practitioners should move exposure prevention into the release pipeline and pair it with rapid credential lifecycle control.
For practitioners
- Remove server-side credentials from client-delivered assets Keep signing keys, internal application secrets, and server-to-server tokens out of JavaScript bundles, source maps, global objects, and config responses.
- Scope any unavoidable third-party key to the browser context Use referrer, IP, quota, and feature-specific restrictions so a leaked key cannot be reused outside the intended page or domain.
- Treat confirmed exposure as a revocation event Rotate or revoke any secret once it is verified in shipped code, even if the report is later classed as informative or duplicate.
- Strip or gate production source maps Prevent full frontend source from being recoverable in production, because source maps often reveal both the secret and the surrounding implementation details.
- Add release checks for secret-bearing responses Block deployment when frontend build artefacts or API responses contain API keys, bearer tokens, or signing material that should remain server-side.
Key takeaways
- Secrets shipped to browsers are exposed by design, not by accident, because anything delivered client-side can be inspected and reused.
- The most dangerous cases are signing secrets and internal credentials, which can turn disclosure into forged identity events or unauthorised API access.
- The practical control is upstream prevention plus immediate rotation when exposure is confirmed, because severity labels do not undo client-side reachability.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on secrets shipped into browser-delivered code and exposed to anyone who loads the page. |
| NHI-07 — Long-Lived Secrets | Exposed keys remain useful until rotated, making secret lifetime a core part of the risk. | |
| Recommendation — Prevent secret leakage by keeping credentials out of client-delivered assets and revoking anything confirmed in production code. Shorten secret lifetimes and rotate any credential that appears in frontend bundles or source maps. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The threat pattern is credential recovery from shipped assets, which enables downstream misuse. |
| Recommendation — Map browser-exposed secrets to TA0006 and hunt for client-delivered artefacts that reveal live credentials. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle control directly applies to exposed API keys and signing secrets. |
| Recommendation — Apply IA-5 to enforce rotation, revocation, and restricted reuse for any exposed authenticator. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Shipped secrets often grant broader access than intended, so entitlement scope is central. |
| Recommendation — Tighten access permissions and entitlements so leaked client-side credentials cannot be reused outside their intended scope. | ||
Key terms
- 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.
- 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 Exposure: Source map exposure occurs when production software ships debugging artifacts that reveal readable source code and internal implementation details. In identity and agent tooling, that can disclose permission logic, tool boundaries, and approval conditions that attackers can use to plan abuse or find weak control points.
- Client Trust: The assumption that the application receiving an OAuth token will handle it correctly and only within approved boundaries. In modern IAM programmes, client trust is a governance decision that must be registered, reviewed, and retired when the integration no longer needs access.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity lifecycle controls to the broader security programme they run every day.
Published by the NHIMG editorial team on September 4, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org