Notifications
Clear all
Topic starter
19/08/2026 3:56 pm
TL;DR: Production JavaScript bundles are increasingly leaking AWS credentials, CI/CD tokens and API keys, and Sprocket Security describes how one Vite misconfiguration exposed live AWS access and CircleCI access that could reach a client’s codebase, pipeline and repositories. The real failure is not just detection, but scanning built artifacts and treating client-side secrets as compromised immediately.
NHIMG editorial — based on content published by Sprocket Security: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
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 client-side secrets create a bigger risk than source-code secrets alone?
A: Because a browser-delivered secret is already outside the protected development boundary and available to any visitor, including attackers and automated scanners.
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.
Practitioner guidance
- Scan built JavaScript artifacts before release Add artifact-level secret scanning to the release pipeline so the exact bundles served to browsers are checked for AWS keys, API tokens, and signing secrets.
- Remove privileged credentials from client-facing prefixes Restrict public environment-variable prefixes to genuinely non-sensitive values and block any credential, token, or secret from being compiled into browser-delivered code.
- Replace static cloud keys with temporary identities Use short-lived cloud roles and scoped temporary credentials for deployment workflows, then revoke any long-lived access keys that were ever embedded in shipped JavaScript.
What's in the full article
Sprocket Security's full article covers the operational detail this post intentionally leaves for the source:
- The headless-browser crawling and JavaScript parsing workflow used to discover secrets across a large client estate.
- The exact validation approach for confirming whether discovered AWS and CI/CD credentials were live and usable.
- The attack chain from exposed browser bundle to S3 access, production code retrieval, CircleCI control and GitHub repository access.
- The practical hardening steps for Vite, source maps and CI/CD artifact scanning that stop the same failure mode from recurring.
👉 Read Sprocket Security's analysis of JavaScript secrets exposure and build-to-deploy compromise →
JavaScript secrets exposure in production bundles: are controls keeping up?
Explore further
19/08/2026 4:34 pm
JavaScript secrets exposure is an identity governance problem, not just a frontend mistake. Once a cloud key or CI/CD token is shipped in a browser bundle, the issue becomes who can authenticate, what they can reach, and whether the identity should still be trusted at all. The article’s example shows that a single exposed credential can bridge application delivery, source control, and cloud access. Practitioners should treat browser-delivered secrets as governed identities with lifecycle and revocation requirements.
A question worth separating out:
Q: What should teams do first when a deployment credential has been exposed in the browser?
A: Contain the identity before anything else. Revoke the credential, review whether it had cloud, CI/CD, or repository permissions, and map any secrets or systems reachable through that path. Then inspect the build pipeline and related templates so the same exposure cannot recur in later releases.
👉 Read our full editorial: JavaScript secrets exposure is becoming a build-to-deploy risk
