TL;DR: Thousands of active secrets were found exposed in JavaScript bundles across 5 million apps, showing that front-end code can leak API keys, AWS access, and Slack access in ways common DAST tooling misses, according to Intruder research. The practical problem is not just detection, but governance over secrets that ship into client-side assets before they are ever executed.
At a glance
What this is: Intruder's research says JavaScript bundles are exposing active secrets in front-end code, turning client-side assets into a hidden credential leakage path.
Why it matters: This matters because application, cloud and identity teams need controls that find and govern secrets before they are baked into browser-delivered code, where DAST alone may not see them.
Context
JavaScript bundle secrets exposure is a governance problem, not just a scanning problem. When build processes place API keys and similar credentials into browser-delivered assets, those secrets can be recovered long before a traditional application scan would flag them. That creates a front-end attack surface where confidentiality depends on what is bundled, not just what is executed.
The identity angle is direct because API keys, tokens and other machine credentials are non-human identities in practice. If they ship into client-side code, security teams lose lifecycle control over where the credential lives, who can see it and when it should be revoked. Intruder's findings fit a broader pattern of secrets sprawl moving into places existing control models were not built to govern.
Key questions
Q: What fails when API keys are shipped in JavaScript bundles?
A: The failure is that a build-time secret becomes a publicly retrievable client-side artefact. Once the bundle is delivered to browsers, anyone who can download the file can extract the credential and use it until it is revoked. That is a governance break, not just a scanning miss, because the secret has already left the intended trust boundary.
Q: Why do exposed developer credentials and secrets create such a high-risk path for attackers?
A: Exposed credentials matter because they bypass many defensive layers and give attackers immediate, legitimate-looking access. In cloud and development environments, a single token, key, or private credential can unlock repositories, workloads, or crypto assets, especially when standing access and weak monitoring are in place. Attackers prefer these paths because they are faster and quieter than exploiting software flaws.
Q: What signs show that secret scanning is missing front-end exposure?
A: A common sign is when repository scans look clean but production bundles still contain active credentials. Another indicator is when DAST and application testing report no issue while users can still retrieve keys directly from static JavaScript files. That mismatch means the inspection boundary is wrong and release artefacts are not being checked.
Q: Should teams prioritise bundle scanning or secret rotation first?
A: Teams should do both, but bundle scanning comes first when the leak path is still active. Rotation limits damage after exposure, while bundle scanning prevents new credentials from shipping into browser-delivered code. If the release pipeline keeps reintroducing secrets, rotation alone becomes a recurring containment exercise rather than a durable fix.
Technical breakdown
Why JavaScript bundles leak secrets before runtime
Modern front-end build pipelines often minify and bundle application code into static JavaScript files that browsers download openly. If secrets are embedded during build time, they are no longer protected by server-side boundaries and can be recovered by anyone who can fetch the asset. This is different from runtime compromise because the leak exists in the delivered artefact itself, not in live execution. Traditional DAST focuses on application behaviour and server responses, so it can miss secrets already exposed in static client assets. The control gap is therefore between build governance and application testing.
Practical implication: treat front-end bundles as a secret-bearing surface and scan build outputs before release.
Why common secrets detection misses front-end exposure
Secrets detection tools are often tuned for repositories, environment variables or backend configuration, but JavaScript bundles are a noisier target because values may be transformed, concatenated or partially obfuscated. That makes pattern-based detection less reliable unless it is paired with file-type awareness and context about where the bundle will be served. The issue is not that the secrets are invisible, but that they appear in a distribution format many controls do not inspect deeply enough. For IAM and NHI teams, the lesson is that detection must follow the distribution path, not just the source repo.
Practical implication: extend secret scanning to packaged front-end artefacts and verify that release pipelines inspect the final bundle.
How exposed API keys expand blast radius across cloud and SaaS
An exposed API key is rarely just a credential for one application. Depending on scope, it can open access to cloud resources, SaaS workspaces, automation hooks or downstream service integrations. That makes the blast radius a function of privilege design, not just exposure location. If the same key can reach AWS, Slack or other connected services, front-end leakage becomes a cross-domain control failure spanning application security, secrets governance and identity lifecycle management. The article's point is therefore broader than front-end hygiene: it is about how much trust organisations place in reusable machine credentials.
Practical implication: classify exposed keys by privilege scope and revoke or rotate any credential that can reach production services.
Threat narrative
Attacker objective: The attacker seeks to turn front-end code exposure into authenticated access to downstream services and data using leaked machine credentials.
- Entry occurs when a build script or front-end packaging step inserts active API keys into JavaScript bundles that are publicly served to browsers.
- Credential access follows because an attacker can retrieve the bundle directly and extract reusable machine secrets from the static file.
- Impact comes when those keys are reused to access cloud environments, Slack workspaces or other connected services with whatever privilege the key carries.
Breaches seen in the wild
- 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
Front-end bundle secret leakage is a machine-identity governance failure. Once API keys are compiled into JavaScript, they stop behaving like controlled credentials and start behaving like exposed artefacts. That shifts the problem from runtime access control to pre-deployment secret governance, which many application teams still treat as a code-quality issue rather than an identity risk. Practitioners should govern bundle output as part of the credential lifecycle.
Secrets detection that stops at the repository misses the real trust boundary. The relevant boundary is the shipped artefact, not only the source tree. If scanners do not inspect final bundles, organisations can pass source-based checks while still distributing active secrets to every browser session. Practitioners should align secret discovery with release artefacts and build outputs, not just code commits.
JavaScript bundle exposure shows why NHI lifecycle controls must extend into DevSecOps. API keys, OAuth tokens and similar machine credentials need ownership, scope review and revocation paths that account for front-end packaging. When those controls are absent, secrets sprawl becomes a delivery problem as much as an inventory problem. Practitioners should treat front-end credential leakage as an NHI governance defect, not a narrow web vulnerability.
Blast-radius design matters more than detection confidence when client-side secrets are involved. Even if detection catches some exposed credentials, the practical question is how much access each secret can reach before revocation. Least privilege, short scope and rapid revocation reduce the damage window when a bundle leak occurs. Practitioners should minimise the privilege attached to any credential that could ever surface in client-delivered code.
Secret Leakage: JavaScript bundle exposure is a concrete form of secret leakage that creates a durable attack surface after release. The implication is that release engineering, security testing and identity governance need to converge around packaged artefacts, not operate as separate controls. Practitioners should build one governance model for how secrets enter, move through and leave front-end delivery.
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.
- Read next: API Key Management Guide
What this signals
Front-end bundle leakage extends NHI governance into the release pipeline. Secrets are no longer only a repository hygiene issue when they are compiled into browser assets. Security teams should assume that any credential embedded in client-delivered code has already crossed the boundary from hidden secret to exposed machine identity, which changes how quickly revocation and scope reduction need to happen.
Browser-delivered code creates an inspection blind spot unless controls move to artefact-level governance. Source scans, DAST and code review each cover part of the path, but none of them fully answer what was actually shipped. Practitioners should make packaged artefacts a first-class control point and use the release process to enforce secret detection before exposure becomes public.
Secret Leakage: front-end bundles now behave like a distribution channel for hidden credentials, which means the security team has to manage them as governed assets rather than disposable code outputs. That requires tighter ownership of API keys, shorter credential lifetimes and explicit revocation paths when a bundle leak is discovered.
For practitioners
- Scan release bundles, not just source code Add checks to the build and release pipeline that inspect final JavaScript artefacts for embedded API keys, tokens and other secrets before deployment.
- Classify every exposed credential by blast radius Map each leaked key to the cloud, SaaS or internal service it can reach, then revoke any credential whose scope cannot be tightly justified.
- Move secrets out of client-delivered code Replace hard-coded front-end secrets with server-side retrieval, delegated access or short-lived tokens that are not embedded in browser assets.
- Add front-end secret checks to release gates Make bundle inspection a mandatory gate in CI/CD so packaged assets cannot ship if they contain credentials or other reusable secrets.
- Reduce privilege on any credential that may surface Limit the permissions on API keys and service tokens to the smallest possible scope so a leak in a JavaScript bundle cannot open broad access.
Key takeaways
- JavaScript bundle secret leakage turns front-end assets into a credential exposure channel that many common scanning approaches do not fully cover.
- The article reports thousands of active secrets found across 5 million apps, which shows the scale of the exposure problem.
- The practical fix is to move secret control earlier in the delivery pipeline and reduce the blast radius of any credential that could reach client-side code.
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 OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | JavaScript bundles exposing API keys is a direct secret leakage pattern. |
| NHI-07 — Long-Lived Secrets | Reusable client-side credentials stay exposed until rotation or revocation ends their usefulness. | |
| Recommendation — Scan packaged front-end artefacts for embedded secrets and revoke any leaked credentials immediately. Replace long-lived keys with short-lived credentials and enforce rotation on any secret that could ship in a bundle. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IA-5 governs credential lifecycle controls that this leakage problem exposes. |
| Recommendation — Apply authenticator management to rotate exposed keys and prevent credentials from being embedded in distributed code. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account and credential governance are central when exposed keys grant downstream access. |
| Recommendation — Use account management controls to inventory, scope and revoke credentials that appear in client-side assets. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Leaked API keys can become broken authentication failures for services that trust them blindly. |
| Recommendation — Review API authentication paths so leaked client-side keys cannot be reused as valid credentials. | ||
Key terms
- JavaScript Bundle: A JavaScript bundle is the compiled front-end asset that a browser downloads to run an application. It often merges code, configuration, and dependencies into one distributable file, which can accidentally preserve secrets if build-time hygiene is weak.
- Client-side Secret Exposure: The leakage of keys, tokens, or sensitive configuration inside a mobile application where attackers can extract them through reverse engineering, memory inspection, or code modification. It is a governance failure as much as a technical one because the credential lifecycle was never properly bounded.
- Attack Surface Management: Attack surface management is the practice of finding and evaluating assets that could be exposed to misuse or compromise. CAASM focuses on internal visibility across the environment, while EASM focuses on externally reachable assets. It is a discovery discipline, not a complete identity control model.
- Machine Credential: A machine credential is a secret or identity artifact used by software rather than a person. It includes service account credentials, API keys, tokens, and certificates. In practice, the main risk is not just exposure, but unmanaged lifecycle, unclear ownership, and overbroad access.
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 helps security and platform teams build the controls needed to govern credentials across modern delivery pipelines.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org