TL;DR: Secrets hidden in JavaScript bundles, build outputs, and single-page application front ends can escape traditional scanners, with large-scale testing finding hundreds of high-impact tokens and broad exposure across code, ticketing, and collaboration systems, according to Intruder. The governance gap is not discovery alone, but failure to scan runtime-facing artefacts and revoke exposed credentials fast enough.
At a glance
What this is: Intruder shows that JavaScript bundles and single-page application front ends can hide active secrets from traditional scanning approaches that stop at the base URL.
Why it matters: This matters because IAM and NHI teams cannot rely on code-only controls when runtime-facing artefacts can expose usable tokens, keys, and downstream access paths.
Context
JavaScript bundle secrets exposure is a governance gap, not just a detection gap. Traditional scanners often inspect the base page and a narrow set of known secret locations, but modern front ends package executable code and configuration into assets that are loaded later and handled outside classic shift-left assumptions.
That creates direct identity risk because the leaked material is not abstract code noise. The article describes repository tokens, project-management API keys, and messaging credentials that can authenticate as services or automation paths, which means NHI governance has to extend beyond source code into build outputs and deployed web assets.
Key questions
Q: What breaks when secrets are only scanned in source code and not in deployed front-end assets?
A: The control fails because the secret can be introduced during build or packaging and then shipped inside a browser-delivered bundle. Source-only scanning misses that exposure path, so teams keep a live credential in production even though the repository looked clean. Effective governance must inspect deployed artefacts, not just committed code.
Q: Why do exposed JavaScript bundle secrets create such a high-risk access problem?
A: Because the leaked value is usually an active credential, not a harmless string. If it authorises access to repositories, ticketing, chat, or automation systems, the exposure becomes a non-human identity problem with real privileges, ownership questions, and revocation urgency. The risk is authentication, scope, and downstream access abuse.
Q: What do security teams get wrong about secret scanning in web applications?
A: They often scan repositories and commits but ignore the compiled output that users actually download. That misses build-time misconfigurations where a safe-looking variable is transformed into a public credential in the shipped bundle. The control gap is between source review and release artifact inspection, not between detection tools and attackers.
Q: Should organisations treat leaked API keys from front-end code as an incident response issue?
A: Yes, because a front-end leak is an authenticated access event waiting to be used. Teams should revoke the exposed secret, assess where it was valid, and check linked systems for repository, ticketing, messaging, or automation abuse. The response should be driven by credential scope, not by the file where the secret was found.
Technical breakdown
Why base-URL scanning misses JavaScript bundle secrets
Many vulnerability scanners inspect the initial HTTP response and pattern-match for known secret formats, but they do not follow the application’s client-side dependency chain. In a single-page application, the dangerous material often sits in compiled JavaScript files loaded after the first page request, which means the scanner never sees the file where the token lives. That is a coverage problem, not a regex problem. The same limitation affects any workflow that assumes the base URL is the whole application surface. Practical implication: extend scanning to fetch and inspect runtime-loaded JavaScript assets, not just HTML entry points.
Practical implication: Add spidering or asset-enumeration coverage for front-end bundles before declaring a secret scan complete.
Why DAST and SAST each miss part of the secret exposure problem
SAST can catch secrets committed to code, and DAST can sometimes crawl more deeply than a basic scanner, but neither covers the full lifecycle of a secret that is injected during build or exposed only in deployed assets. The article’s example of build-time variable injection shows why the control boundary matters: a secret may never be present in source control, yet still appear in the production bundle. That is a lifecycle failure across code, build, and runtime, not a single-tool blind spot. Practical implication: treat secret discovery as a pipeline-wide control spanning source, build artefacts, and deployed front-end output.
Practical implication: Map secret detection to the full delivery chain so build-time injection and runtime exposure are both tested.
How front-end secrets create downstream NHI and API abuse
When a JavaScript bundle contains an active API key or access token, the secret acts as a non-human identity credential with real privileges. In the article, some exposed tokens could reach private repositories, ticketing systems, Slack channels, and automation platforms, which means a front-end leak can quickly become privileged access to operational systems. The security issue is therefore not just disclosure, but delegated access with unclear ownership and revocation latency. Practical implication: classify front-end-exposed tokens as NHI assets and bind them to inventory, scope, and revocation controls.
Practical implication: Treat exposed front-end tokens as governed NHI credentials with ownership, scope, and rapid revocation requirements.
Threat narrative
Attacker objective: The attacker’s objective is to convert a publicly exposed front-end secret into authenticated access to internal systems and operational data.
- Entry occurs when a secret is embedded in a JavaScript bundle or build output that is publicly reachable from the application front end.
- Credential access follows when the exposed token, API key, or repository secret is extracted from the asset and validated as active.
- Impact follows when the token is used to reach private repositories, ticketing systems, chat channels, or downstream SaaS and automation services.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
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 secret exposure is an NHI governance problem because the credential now lives outside the places most teams inventory. A token embedded in a JavaScript bundle is still a live machine credential, even if it never appears in source control. The control failure is that ownership, scope, and revocation are often managed as if only code repositories matter. Practitioners need to treat deployed artefacts as part of the credential estate.
Shift-left tooling is necessary but insufficient when the secret is introduced after source scanning has finished. Build scripts, environment-variable injection, and bundle generation can create a late-stage exposure path that classic pre-merge checks will never see. That means the governance model has to include build and release artefacts, not just repositories and tickets. Practitioners should verify controls at build time and at runtime.
JavaScript bundle secrets exposure is a form of secret sprawl at the edge of the application. The same credential can exist in code, build output, browser-delivered assets, and third-party systems such as chat or ticketing platforms. That multiplies the remediation burden because the issue is not one leak, but the reuse of the same access path across environments. Practitioners need a single inventory and revocation workflow for all exposed machine credentials.
Runtime-facing artefact scanning deserves to sit beside repository scanning in the security baseline. Traditional scanners optimize for known file locations, but front-end bundles and single-page applications shift the discovery problem into deployed content. That makes spidering, asset enumeration, and post-build validation core controls rather than optional depth checks. Practitioners should make deployed front-end inspection a standard part of secret governance.
Secret leakage in front-end code is especially dangerous because the exposed object is usually more privileged than teams assume. In this article, the leaked credentials were capable of repository access, internal ticketing, and messaging actions. That is a governance failure in privilege scoping, not just detection. Practitioners should assume every leaked token can be used until proven otherwise and design controls around that assumption.
From our research library:
- 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
- Read next: API Key Management Guide
What this signals
Runtime bundle inspection should become a baseline control for teams that still rely on shift-left secret scanning. A secret that appears only after build and bundling is invisible to repository-first workflows, so practitioners need a post-build validation step that inspects deployed front-end assets as part of release governance.
Secret exposure at the front end creates a revocation problem, not just a discovery problem. When exposed credentials remain valid long enough to be useful, the organisation has already lost control of the credential lifecycle, which is why detection and revocation need to be linked operationally.
Long-lived API keys are still too common in machine identity estates: 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report. That pattern matters here because an exposed browser-delivered token is only manageable if it can be owned, scoped, and revoked quickly.
For practitioners
- Extend scanning beyond base URLs Spider JavaScript bundles, chunk files, and other runtime-loaded assets so deployed front-end secrets are inspected after build and before exposure.
- Validate build-time injection paths Review build scripts that pass environment variables into production bundles and restrict them to the intended variables only, not the full process environment.
- Classify exposed front-end tokens as NHI credentials Assign ownership, scope, and revocation responsibility to every token or key that can authenticate from a browser-delivered asset.
- Add post-build verification to release gates Test generated artefacts for secrets after packaging, because source control checks alone will miss build outputs and injected front-end credentials.
- Tighten revocation for any exposed secret Assume active exposure when a token appears in a bundle and remove access before investigating downstream impact across repositories, tickets, and chat systems.
Key takeaways
- JavaScript bundle secrets exposure shows that shift-left scanning can miss live credentials once they are moved into deployed front-end artefacts.
- The issue is not only secret discovery, but credential governance across build outputs, browser assets, and downstream systems that the token can reach.
- Teams reduce risk by inspecting runtime-loaded JavaScript, tying exposed tokens to NHI ownership, and revoking access as soon as exposure is confirmed.
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 | Front-end bundles exposed active secrets that scanners missed until after deployment. |
| NHI-07 — Long-Lived Secrets | The article shows active tokens remaining usable after exposure, which is the long-lived secret problem. | |
| Recommendation — Scan deployed JavaScript assets for secret leakage and revoke any exposed credentials immediately. Replace long-lived browser-exposed credentials with short-lived alternatives and rapid revocation paths. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle governance is central when exposed tokens remain valid in front-end code. |
| Recommendation — Apply authenticator management controls to rotate and revoke exposed machine credentials without delay. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The exposure enables direct credential access to downstream systems and services. |
| Recommendation — Map front-end secret leaks to Credential Access and hunt for active token abuse in connected services. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Leaked tokens were able to reach repositories, tickets, and chat systems, so entitlement scope is material. |
| Recommendation — Review token entitlements against PR.AA-05 and strip any permissions not needed for the intended workflow. | ||
Key terms
- JavaScript Bundle Secret Exposure: A JavaScript bundle secret exposure happens when an access token, API key, or other credential is embedded in client-side code delivered to the browser. The secret is then publicly retrievable from the application artefact, not from the source repository alone, which makes build and runtime controls essential.
- Shift-Left Scanning: Shift-left scanning finds security issues before code or infrastructure reaches production. It runs checks on container images, infrastructure as code, or other pre-deployment artefacts so development teams can fix risks earlier, when remediation is usually faster and less disruptive to operations.
- Runtime-Facing Artefact: A runtime-facing artefact is any file or asset served to users or loaded by the application after deployment, such as JavaScript chunks, templates, or generated configuration. These artefacts can contain secrets that never appear in the original repository scan, so they need separate inspection.
- Credential Lifecycle Governance: Credential lifecycle governance is the set of controls that manage creation, assignment, monitoring, rotation, and retirement of credentials. For machine identities, it prevents secrets from becoming permanent access artifacts and ensures every identity has a defined owner, purpose, and end state.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It helps practitioners align credential governance with the operational reality of exposed tokens and service access.
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