Configuration
Source maps in production: convenient for you, useful for attackers.
A source map lets a browser reconstruct your original, unminified source from the bundled code that actually ships. Left enabled in production, it hands anyone who opens dev tools your real source, complete with comments, file structure and any secrets you assumed were buried in the bundle.
They turn your shipped bundle back into your codebase.
Minified production code is hard to read, and many teams quietly rely on that for a little obscurity. A source map removes it entirely. With source maps served in production, an attacker opens the browser tools and reads your front end as clean, commented source, laid out in your original file structure. It is the difference between an attacker guessing at your app and reading it.
What a source map actually reveals
Source maps expose your original file and folder names, which often map straight to your app's internal structure and hint at the backend. They restore comments, including the honest ones that describe what a workaround does or which endpoint is fragile. They reveal logic that minification had scrambled, making it easy to find client-side checks to bypass, feature flags to flip, and endpoints to target.
They also surface anything you left in the code assuming no one would read it: hard-coded values, internal URLs, and the occasional secret that should never have been in the front end in the first place. A source map does not create these problems, but it makes finding them effortless.
Is it always a problem?
Source maps are not a vulnerability by themselves, and plenty of teams ship them deliberately for error monitoring. The risk is contextual: your front-end code is already delivered to the browser, so a source map exposes structure and readability, not anything that was truly secret if your app is otherwise built correctly. The danger is that most apps are not otherwise built correctly, and the source map is what makes their other weaknesses easy to find.
So the honest position is: source maps in production are a meaningful information leak that lowers the effort to attack you, and there is rarely a reason to serve them publicly. If you want them for error tracking, upload them privately to your monitoring tool instead of serving them to every visitor.
How to check and fix
Open your deployed app's dev tools and look at the sources panel. If you can read your original, commented source with real file names, your source maps are public. You can also check whether .map files are being served alongside your JavaScript bundles.
The fix is a build setting. Disable public source map generation for production builds, or configure your bundler to generate them and upload them privately to your error-monitoring service rather than deploying them. Then redeploy and confirm the sources panel now shows only minified code.
Common questions.
- Are source maps a security vulnerability?
- Not on their own. They are an information disclosure that makes your app far easier to read and therefore to attack. On a well-built app the impact is limited to structure and readability; on a typical app it hands an attacker a map to the real weaknesses. Either way there is rarely a reason to serve them publicly.
- But I need source maps for error tracking.
- Then generate them and upload them privately to your monitoring tool, which is the standard pattern. Your errors get readable stack traces without the maps being served to every visitor of your site.
- Do you check for this in an audit?
- Yes. Reviewing what your front end exposes, including source maps, readable secrets and internal structure, is part of every security audit we run.
Related services.
Let's build something real.
Tell us about your app or idea. You'll get a clear plan and a fixed quote back within 24 hours.