Notifications
Clear all
Topic starter
19/08/2026 3:50 pm
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.
NHIMG editorial — based on content published by Intruder: LLMjacking and related research on JavaScript bundle secrets exposure
Questions worth separating out
Q: How should security teams handle secrets embedded in JavaScript bundles?
A: Teams should treat bundled secrets as production credentials, not harmless code residue.
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.
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.
Practitioner guidance
- Scan compiled front-end artifacts Inspect JavaScript bundles, source maps, and build outputs for API keys, tokens, certificates, and embedded configuration before release.
- 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.
- Classify exposed keys as NHIs Assign ownership, scope, and expiry to every API key or token that could appear in front-end assets.
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.
👉 Read Intruder’s analysis of JavaScript bundle secrets exposure and front-end attack surfaces →
JavaScript bundle secrets detection: are your controls keeping up?
Explore further
19/08/2026 4:26 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: JavaScript bundle secrets exposure is widening front-end attack surfaces
