An exposed source map is a .map file, publicly reachable next to a production JavaScript bundle, that maps the minified code back to its original, unminified source — including original file names, function and variable names, and code comments. If a production deploy ships .map files publicly, anyone can reconstruct something very close to your original source code, not just the compiled output.
Why this is worse than it sounds
A minified bundle alone is already somewhat readable with effort, but a source map removes that friction entirely — it hands back original variable and function names, file structure, and any comments left in the code, which frequently include TODOs, internal API notes, or logic explanations never meant to be public. Combined with any other finding (an exposed key, a CORS gap), a readable source map makes it dramatically easier for an attacker to understand how your app's internals connect.
Why AI-generated builds often ship them
Most build tools generate source maps by default in production builds because they're valuable for debugging — Next.js, Vite, and Create React App all produce them out of the box unless explicitly disabled. A build config generated by an AI tool, or left at framework defaults, ships them to the public web exactly like it ships the JavaScript itself.
How to disable them
In Next.js, set productionBrowserSourceMaps: false in next.config.js. For other bundlers, the equivalent flag is usually a build-time option (Vite: build.sourcemap: false, webpack: devtool: false for production). If you need maps for your own error-tracking pipeline, upload them privately to your error-monitoring provider instead of serving them publicly.
Frequently asked
Do I need source maps for error tracking if I disable them publicly?
Yes, and you can have both — most error-tracking tools (Sentry and similar) support uploading source maps privately during your build/deploy step, so you get readable stack traces without ever serving the .map file on the public web.