Exposed source maps in production
The minified JavaScript your browser runs is nearly unreadable. The source map next to it turns that back into your original, commented, file-by-file source code — for anyone who requests it.
Source maps enabled locally or on a staging environment behind auth. They're genuinely useful for debugging — matching a stack trace back to real source lines is most of the point of having them.
The same .js.map files publicly reachable on your production domain, next to the bundle they describe — which is the framework default unless someone turns it off.
Why this ships to production by default
Most modern build tools generate source maps automatically because they're valuable during development, and nothing about a standard production build stops that generation — it has to be explicitly turned off. AI-generated scaffolds copy whatever the framework's default build command does, and the framework's default is "generate them." The map files then get deployed alongside the bundle they describe, publicly, because nobody wrote a step to exclude or gate them.
How to check if you're affected
Open your production site, find any JavaScript file your browser loads (devtools → Network → JS), and request that same URL with .map appended. If it returns real JSON instead of a 404, your source map is publicly reachable — and so, most likely, is the readable source for the rest of your bundle.
The fix
In Next.js, disable public source maps at the framework level:
// next.config.js
module.exports = {
productionBrowserSourceMaps: false,
};If you rely on source maps for error tracking (Sentry and similar tools), keep generating them at build time and upload them directly to your error-tracking provider as a private build step, instead of deploying them to your public server. You keep readable stack traces in your dashboard; the public copy an attacker could fetch never exists.
Not sure what's publicly reachable on your app?
StackSecured checks your live production build for exposed source maps, config files, and secrets — the same way an attacker would look.
Run a free scanCommon questions
Do source maps leak secrets directly, like API keys?
+
Not usually on their own — a source map reconstructs your original, readable source code and file structure from the minified bundle a browser actually runs. It won't hand over a secret that was never in your frontend code to begin with. It will hand over any secret that was hardcoded into your frontend by mistake, plus your full application logic, internal comments, and file layout — which makes finding every other vulnerability dramatically easier.
Will disabling source maps break my error tracking (Sentry, etc.)?
+
No — the standard pattern is to still generate source maps at build time, but upload them directly to your error-tracking provider via their build step instead of shipping them to your public server. Your error tracker can still symbolicate stack traces using its private copy; the public copy attackers could otherwise fetch simply never exists.
Is this the same issue as an exposed .env file?
+
Same category of mistake — something meant for developers, not the public, ends up publicly reachable — but a different exposure. A leaked .env file hands over secrets directly. A leaked source map hands over your actual application logic, which is usually a bigger, slower-to-fix problem: rotating a key takes minutes, and this can reveal business logic flaws, not just credentials.
More reading: Exposed API keys in AI-built apps · Firebase security rules misconfiguration · Vibe-coding security statistics 2026