What Your JavaScript Bundle Tells an Attacker

Every modern web application ships JavaScript to the browser. That JavaScript is a treasure map. Most security researchers skip right past it, firing up their scanners and looking for injection points. Meanwhile, the JS bundle is sitting there in plain text, full of secrets the development team never intended to expose.

Here is what we routinely find in production JavaScript bundles: staging and development hostnames that map internal infrastructure, API keys for third-party services, feature flag configurations that reveal unreleased functionality, internal service names that expose the backend architecture, and authentication endpoint paths that are not documented in any public API.

We have found these issues at multiple companies. At CLEAR, the identity verification company, the JavaScript bundle exposed internal configuration data. At Exness, a major forex broker, similar patterns revealed details about their backend services. These are not edge cases. This is the norm for large web applications.

The technique is simple. Download the JavaScript bundle files from the target application. Run them through a beautifier to undo minification. Then search for patterns: URLs, domain names, anything that looks like a key or token, environment variable names, error messages that reference internal services. Source map files are even better. If a company accidentally publishes their source maps, you are reading the original unminified source code with comments.

Build tools like Webpack and Vite embed environment variables at build time. If the build process has access to staging URLs, API keys, or internal hostnames, those values end up in the production bundle. Most teams do not audit what their build pipeline injects into client-side code.

If you are a researcher, JS bundle analysis should be the first thing you do on any web target. If you are a developer, audit your bundles. Search for anything that looks like it should not be public. You will probably find something.