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 issue highlights research showing that JavaScript bundles can expose active secrets in front-end code, creating a client-side credential leakage problem that traditional DAST tools do not reliably catch.
Why it matters: For IAM, PAM, and NHI teams, this matters because leaked API keys and tokens turn application code into a secret distribution channel, widening the blast radius of identity and access failures across cloud, collaboration, and workload systems.
👉 Read Intruder’s analysis of JavaScript bundle secrets exposure and front-end attack surfaces
Context
Client-side code often receives less governance than backend systems, yet it can still carry the credentials that unlock cloud, messaging, and application environments. When secrets are embedded in JavaScript bundles, the exposure is not theoretical: the browser-delivered asset becomes part of the attack surface, and standard scanning approaches may miss it because they are tuned for server-side or repository-based leakage. This is a JavaScript bundle secrets detection problem first, and an identity governance problem immediately after.
The identity angle is straightforward. API keys, tokens, and other secrets are non-human identities in practice because they authorize software actions without a person present. When those credentials are shipped to the front end, organisations lose control over lifecycle, revocation timing, and scope. That is why client-side secret exposure belongs in the same control conversation as secrets management, workload identity, and access review discipline.
Key questions
Q: How should security teams handle secrets embedded in JavaScript bundles?
A: Teams should treat bundled secrets as production credentials, not harmless code residue. Scan compiled artifacts before release, block deployment when credentials are found, and revoke exposed keys immediately. The control objective is to stop secrets from ever leaving the build pipeline in reusable form.
Q: Why do JavaScript bundles create a credential governance problem?
A: Because bundles distribute credentials to every browser that loads them, they erase the distinction between internal secrets and public assets. That breaks lifecycle control, weakens revocation, and turns application code into an ungoverned NHI distribution channel.
Q: How do you know if front-end secret detection is actually working?
A: It is working only if compiled outputs are scanned, false negatives are measured, and exposed keys are revoked before attackers can replay them. If a secret can survive the build process and reach production unchanged, the control is not effective.
Q: What should organisations do when a public bundle exposes an API key?
A: Treat the key as compromised, rotate it at once, inspect downstream services for misuse, and review whether the key had broader privileges than the application needed. If the credential cannot be scoped tightly, the incident usually reveals a larger access design problem.
Technical breakdown
How secrets end up in JavaScript bundles
Modern front-end build pipelines assemble environment variables, libraries, and application logic into static assets that are delivered to every user browser. If a developer hardcodes an API key, leaves a token in a config file, or references a secret during build time, that value can be embedded into the bundle and copied anywhere the file is cached, downloaded, or mirrored. Unlike server-side secrets, these values are no longer protected by runtime isolation. They become public by design unless the build and release process strips them out before deployment.
Practical implication: treat build output as a secret-exposure checkpoint and block releases that contain credential material.
Why traditional DAST and repo scanning miss front-end exposure
DAST tools focus on observable runtime behaviour, while repository scanners focus on source code and commit history. JavaScript bundles sit between those layers, which creates a blind spot when secrets only exist after compilation or minification. A key may never appear in a repository in a recognisable form, and it may not be exercised by a scanner that only inspects live endpoints. This is why front-end secret detection needs artifact-level analysis of the generated asset, not just the source tree or the running application.
Practical implication: add artifact scanning for compiled bundles to your release pipeline and make it a gated control.
What leaked API keys mean for NHI governance
An exposed API key is not just a code quality issue. It is a credential with identity, scope, and lifecycle, which means it needs the same governance discipline as other non-human identities. Once a key is exposed in a bundle, the attacker inherits whatever privileges that secret carries, often without user interaction or MFA friction. The security problem is therefore about standing access, weak scoping, and slow revocation. In NHI terms, this is an unmanaged credential lifecycle failure that turns deployment artifacts into access channels.
Practical implication: classify front-end secrets as governed NHIs and enforce rotation, scope minimisation, and rapid revocation.
Threat narrative
Attacker objective: The attacker aims to turn a client-side secret leak into authenticated access that can be reused for data theft, service abuse, or lateral movement.
- Entry occurs when an attacker discovers an exposed JavaScript bundle or related front-end artifact that contains a usable API key, token, or other secret.
- Escalation follows when that credential is replayed against cloud, collaboration, or application APIs to obtain authenticated access that the front end should never have exposed.
- Impact occurs when the attacker uses the stolen secret to enumerate data, manipulate services, or widen access into connected environments before the credential is revoked.
NHI Mgmt Group analysis
Front-end secret leakage is a governance failure, not a tooling footnote. When API keys reach JavaScript bundles, the organisation has already lost control over where those credentials travel and who can reuse them. DAST, repo scanning, and code review each cover part of the problem, but none of them alone govern compiled artifacts as a secret-bearing distribution layer. The practical conclusion is that the release pipeline must be treated as an identity control point.
Compiled artifacts create a new secrets sprawl surface that many programmes still ignore. The industry has spent years focusing on repositories and vaults, yet build outputs are now a parallel path for credential leakage. That makes client-side bundles part of the NHI estate, because they can contain usable authentication material with real privileges. Teams that do not include build artifacts in their secret inventory are missing a major exposure path.
JavaScript bundle secrets detection should be treated as a control objective, not a point solution. The right model combines pre-commit checks, build-time secret scanning, release gating, and rapid revocation when exposures are found. OWASP-NHI is relevant here because the exposed asset is often a non-human credential with no human approval path. Practitioners should measure whether secrets can survive the build process at all, not just whether they can be found later.
Client-side credential exposure narrows the distance between application security and identity security. Once an API key is embedded in front-end code, the security team is no longer just defending software integrity, it is defending delegated access. That changes how IAM, PAM, and application security teams share responsibility for credentials embedded in code, especially where those secrets grant cloud or SaaS access. The field should treat front-end secret governance as part of broader identity lifecycle control.
What this signals
Secret-bearing build outputs need to become a standard control surface. As front-end applications, AI services, and managed integrations multiply, more credentials will appear outside the places traditional scanners were built to inspect. Teams should pair artifact scanning with revocation automation and connect both to Guide to the Secret Sprawl Challenge and NIST SP 800-53 Rev 5 Security and Privacy Controls.
The next maturity step is not better keyword matching, it is governance over where secrets can exist at all. If a credential can be compiled into a browser-delivered asset, the programme has already lost separation between development convenience and operational trust.
Build artifact control will increasingly define whether IAM and application security operate as one programme. The practical benchmark is simple: if the release pipeline cannot prevent a secret from reaching the browser, then the organisation is depending on post-exposure cleanup rather than preventive governance.
For practitioners
- Scan compiled front-end artifacts Inspect JavaScript bundles, source maps, and build outputs for API keys, tokens, certificates, and embedded configuration before release. Do not rely only on repository scanners or DAST because both miss secrets that appear after compilation.
- Gate releases on secret findings Block deployment when artifact-level scanning detects live credentials, and require a documented revocation step before the same bundle can ship again. Make this part of the CI/CD approval path, not a post-release cleanup task.
- Classify exposed keys as NHIs Assign ownership, scope, and expiry to every API key or token that could appear in front-end assets. That lets IAM and PAM teams track the credential as a managed identity object instead of a generic code secret.
- Rotate and revoke with urgency Assume any credential found in a public bundle has been copied and replayed. Rotate it immediately, check dependent logs for replay activity, and replace long-lived keys with short-lived alternatives wherever possible.
Key takeaways
- JavaScript bundles can leak live credentials into public-facing assets, turning front-end code into an identity exposure channel.
- The important failure is not only discovery, but revocation latency, because exposed secrets often remain exploitable long after detection.
- Practitioners should govern compiled artifacts as part of NHI lifecycle control, with release gating, rotation, and rapid revocation.
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 CSF 2.0, 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-03 | This article centres on exposed secrets and lifecycle failures for non-human credentials. |
| NIST CSF 2.0 | PR.AC-1 | Exposed API keys are an access control failure across the software supply chain. |
| NIST SP 800-53 Rev 5 | IA-5 | IA-5 governs authenticator management, which fits exposed API keys and tokens. |
| CIS Controls v8 | CIS-5 , Account Management | Leaked service credentials need ownership and lifecycle control under account management. |
| MITRE ATT&CK | TA0006 , Credential Access; TA0008 , Lateral Movement | The article describes credential theft followed by reuse against connected services. |
Map leaked bundle secrets to credential access and lateral movement techniques for detection planning.
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.
- Compiled Artifact Secret: A compiled artifact secret is a credential that appears only after code is built, minified, or packaged for release. These secrets are dangerous because source scanning may miss them, while any user who downloads the artifact can potentially retrieve and reuse them.
- 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.
What's in the full article
Intruder’s full issue covers the operational detail this post intentionally leaves for the source:
- The research workflow used to inspect front-end bundles at scale and identify secret-bearing patterns across 5 million apps.
- Examples of the JavaScript bundle secret formats the team found, including where they appear in build output and why traditional tooling missed them.
- The deep-dive on detection limits for common secrets tooling and the remediation approach needed after a bundle exposure is confirmed.
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 for practitioners who need to connect identity controls to operational risk. It is designed for teams responsible for access, lifecycle, and privilege across modern application and cloud environments.
Published by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
