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: This is an analysis of how secrets embedded in JavaScript bundles and front-end build artefacts evade conventional scanning, exposing active tokens and downstream systems.
Why it matters: It matters because IAM, PAM, and NHI teams need controls that cover build pipelines, front-end delivery, and credential revocation, not just source repositories and shift-left checks.
By the numbers:
- The research identified a total of 688 code repository tokens, many of which were still active.
- Intruder says 213 Slack tokens were among the secrets exposed in the scan.
👉 Read Intruder's analysis of JavaScript bundle secrets exposure and scanner blind spots
Context
Secrets exposure in modern web applications is not just a source-code problem. JavaScript bundles, build scripts, and front-end delivery paths can carry credentials into places traditional scanners do not inspect, which leaves a gap between development-time controls and what actually reaches users. For identity and access teams, this is a non-human identity problem because leaked API keys, tokens, and service credentials can immediately become reusable access paths.
Intruder’s article is focused on that gap: why standard regex-based scanning, limited spidering, and selective DAST coverage miss front-end exposures in single-page applications. The governance issue is broader than one detection tool. Organisations that rely on shift-left scanning alone may believe secrets are contained when in practice they are being injected into runtime artefacts, shared services, and collaboration platforms.
The pattern is typical, not exceptional, in modern software delivery because build systems and front-end frameworks routinely assemble sensitive values from multiple places. Once that process is loose, the boundary between code, configuration, and live secrets becomes porous.
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 secrets in front-end code create an IAM and NHI risk?
A: Because the leaked value is usually a usable credential, not just sensitive text. It may authenticate to repositories, ticketing systems, messaging platforms, or cloud services, so the exposure has identity scope, privilege, and lifecycle consequences. Once active credentials are published in front-end code, access governance must treat them like any other compromised non-human identity.
Q: What do security teams get wrong about shift-left for secrets?
A: They often assume early detection equals governance. In practice, governance also requires lifecycle control, monitoring, and revocation after deployment. Without those layers, a secret that was never committed to code can still be exposed, overused, or left active long after it should have been retired.
Q: How do organisations respond when a front-end secret is exposed?
A: They should treat it as a credential compromise, revoke the token, confirm where it was used, and check for downstream access enabled by that identity. If the secret was tied to shared services or broad repository access, scope reduction and follow-up review are necessary before the token can safely be reissued.
Technical breakdown
Why JavaScript bundles are a blind spot for secrets scanners
Many secret scanners start with a base URL, fetch the HTML response, and stop there. That works for obvious leaks in pages and files, but it misses secrets embedded in linked JavaScript bundles because those files contain application logic and often the final injected values produced during build. In single-page applications, the bundle can be the real delivery surface, not a secondary asset. If scanning does not follow the front-end dependency chain, tokens hidden in compiled assets stay invisible even when they are fully reachable in production.
Practical implication: extend scanning to JavaScript bundles and other runtime-delivered assets, not just repository content and first-response HTML.
How spidering changes the detection model for exposed secrets
A spidering scanner follows links, extracts referenced JavaScript files, and inspects their content for secret patterns. That is materially different from a single-request check because it turns the application itself into the search surface. The article also shows why regex quality matters: loose patterns create false positives, while overly narrow patterns miss valid tokens in minified code. The best detection model combines spidering, content-aware filtering, and validation logic that can confirm whether a token is still active.
Practical implication: use crawl-based validation for front-end exposure checks and tune secret patterns against minified production code.
Why exposed secrets become identity and access problems immediately
A leaked token is not just sensitive data. It is a live credential that may represent repository access, ticketing access, messaging rights, or service-to-service permissions. In the examples described, tokens could reach private code repositories, internal tickets, Slack channels, and downstream cloud services. That makes the exposure an IAM and NHI issue because the credential inherits whatever scope, lifecycle, and offboarding state the organisation assigned to it. If revocation is slow or inconsistent, discovery alone does not reduce risk.
Practical implication: treat exposed front-end secrets as credential incidents and trigger revocation, scoping review, and lifecycle reassessment immediately.
Threat narrative
Attacker objective: The attacker’s objective is to turn an exposed front-end secret into authorised access that can be used for data theft, lateral movement, or service abuse.
- Entry occurs when a secret is injected into a JavaScript bundle or build artefact and then served to anyone who loads the application.
- Credential harvesting follows when automated scanners or attackers extract the token from the front-end code and validate whether it is active.
- Escalation and impact occur when the exposed credential provides access to private repositories, ticketing systems, collaboration tools, or downstream cloud services.
NHI Mgmt Group analysis
JavaScript bundle secret exposure is a runtime governance failure, not a scanning nuisance. Once credentials are injected into compiled front-end assets, the control problem moves from source code hygiene to delivery-path governance. Traditional shift-left methods still matter, but they do not cover what users actually download. Practitioners should treat runtime-delivered artefacts as part of the governed credential surface.
Front-end secret leaks create an NHI lifecycle problem the moment a token is issued. API keys, Slack tokens, repository tokens, and service credentials all behave as non-human identities when they can act independently on a system’s behalf. If those identities are duplicated, over-scoped, or left active after exposure, the incident becomes an access governance issue, not just a detection event. The practical conclusion is that lifecycle control must include issuance context, scope, and revocation speed.
Spidering plus validation is the minimum credible model for secrets discovery in modern web apps. The article’s core lesson is that scanning only static repositories or first-response HTML leaves a blind spot at the exact point where front-end applications assemble secrets. That blind spot persists across IAM, PAM, and application security teams because each assumes the other is covering it. Teams should align detection with delivery architecture, not with scanner convenience.
Build pipelines have become the secret injection point that security programmes still under-model. The article shows how environment variables, custom build logic, and front-end packaging can move sensitive values into production artefacts long after developer checks have passed. That pattern broadens the risk surface from code commits to CI/CD output and makes the secret sprawl challenge an operational governance issue. Practitioners should assume build-time injection is part of the credential attack surface.
What this signals
Front-end secret exposure should be treated as a control-plane problem for identity teams, not just an application security issue. The programme implication is clear: if build outputs and browser-delivered assets are not part of your monitoring scope, your credential inventory is incomplete.
Secret sprawl beyond the repository: credentials increasingly move through build systems, collaboration tools, and packaged assets, which means detection must follow the data path rather than the code path. For practitioners, that shifts the focus from isolated scanning to lifecycle control across creation, distribution, and revocation.
For teams building out NHI governance, this is where identity, DevSecOps, and secrets management converge. The next practical step is to pair asset discovery with lifecycle enforcement so that any exposed token can be revoked before it is reused.
For practitioners
- Scan front-end delivery artefacts, not just repositories Add JavaScript bundle inspection and crawler-based checks to your secrets programme so production-delivered assets are covered alongside source code and tickets.
- Treat exposed tokens as credential incidents Route every confirmed leak into the same response path used for NHI or service-account compromise, including immediate revocation, scope review, and downstream access validation.
- Review build injection paths for secret propagation Audit custom build scripts, environment-variable handling, and front-end packaging so sensitive values cannot be injected into production artefacts by mistake.
- Prioritise active-credential validation over regex-only detection Use scanners that confirm whether a discovered token is live, because expired or inert strings do not carry the same operational risk as active access paths.
Key takeaways
- Secrets hidden in JavaScript bundles expose a detection gap that traditional repository-first scanning does not close.
- The impact is measurable because exposed tokens can unlock repositories, ticketing systems, collaboration tools, and downstream cloud services.
- The right response is lifecycle control, with crawler-based discovery, active validation, and immediate revocation when tokens surface.
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 | Front-end token exposure maps directly to secrets rotation and lifecycle gaps. |
| NIST CSF 2.0 | PR.AC-1 | The issue is unauthorized access enabled by exposed credentials. |
| NIST SP 800-53 Rev 5 | IA-5 | Authenticator management is central when leaked tokens remain active. |
| CIS Controls v8 | CIS-5 , Account Management | Leaked tokens behave like accounts and need lifecycle control. |
| MITRE ATT&CK | TA0006 , Credential Access; TA0008 , Lateral Movement | The threat path is credential harvesting followed by access expansion. |
Map leaked front-end tokens to credential access and lateral movement techniques to prioritise detection.
Key terms
- JavaScript Bundle: A JavaScript bundle is the compiled front-end code that browsers download to run a web application. It often contains application logic, configuration values, and build outputs, which makes it a common place for sensitive data to appear if engineering practices are weak.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
- Identity Validation: Identity validation is the process of proving that restored accounts, entitlements, and privileged paths match approved sources and current business need. It is a post-incident control, not a simple technical check, because it determines whether recovery has actually removed attacker access.
What's in the full report
Intruder's full analysis covers the operational detail this post intentionally leaves for the source:
- The JavaScript protocol spidering method used to enumerate bundle assets at scale
- Regex tuning and false-positive reduction techniques for minified front-end code
- Examples of the exact secret types discovered across repositories, ticketing, Slack, and SaaS tools
- Build-process failure modes that caused secrets to be injected into production artefacts
👉 The full Intruder article covers the scanning logic, exposure examples, and build-path root causes.
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 is designed for practitioners who need to connect identity lifecycle control to broader security operations.
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
