What it is
Source maps are designed to be discoverable — that's the whole point. When the developer opens devtools, the browser fetches the `.map` file pointed at by the bundle's `sourceMappingURL` comment and remaps minified stack traces back to original source. Wonderful in development, dangerous in production: the same `.map` file is fetchable by anyone with curl, and inside it sits your TypeScript, your component names, your internal comments, your API path constants, and any string that survived minification by being in a non-minified code path. Public bug bounty programs are full of source-map-leak findings; companies as large as Twitter and Google have shipped them at various points.
How it happens
Modern bundlers (Webpack, Vite, esbuild, Next.js, Rollup) emit a comment at the end of each minified bundle: `//# sourceMappingURL=main.abc123.js.map`. Browsers honor this only when devtools is open, but anyone can fetch the URL directly. The `.map` file is JSON containing your original source files keyed by path, plus mapping data that lets a tool reconstruct exactly what you wrote. Tools like webcrack, source-map-explorer, and shujisr automate the reconstruction — feed them a public bundle and a public map and they output your repo structure as plain TypeScript or JavaScript. Even without the map URL, some bundlers leak via `.map` files that ship without the comment but live at predictable paths.
Common variants
Inline sourceMappingURL
The comment at the bundle's end points at a .map file. Most common shape; most easily exploited.
Predictable .map paths
Even without the comment, bundlers ship .map files alongside .js files at the same path. `main.abc123.js` => `main.abc123.js.map`. Probing for the .map directly works.
Inlined data: URI source map
The map is base64-encoded inline at the end of the bundle (`sourceMappingURL=data:application/json;base64,...`). Same data, slightly less obvious to humans, equally useful to tools.
What an attacker gets
Reveals internal API routes (your component code referenced `/api/admin/users` even though the route never appeared in the rendered HTML), comment-marked TODOs and FIXMEs that read like an attacker's wishlist, internal naming conventions, third-party API keys that survived minification because they were imported from a string constant, and the entire shape of your client logic. Every reverse-engineering task the attacker would otherwise have to do becomes a quick read.
// what fixvibe reports
What FixVibe reports
Runs on every URL scan: paste your app's URL, nothing to install. The free preview shows your top findings; Hobby and above unlock the full report. Each finding shows the affected URL or host, its severity and fix steps you can paste into your AI coding tool.
How to fix it
Emit source maps only for trusted error trackers and strip the discovery comment from the production bundle. Most bundlers support 'hidden' source maps — Webpack's `devtool: 'hidden-source-map'`, Vite's `build.sourcemap: 'hidden'`, Next.js's `productionBrowserSourceMaps: false` (default; or `'hidden'` if you ship them to Sentry). Upload the maps to your error tracker (Sentry's CLI, Bugsnag, Rollbar) at deploy time so stack-trace symbolication still works internally. If you genuinely need public source maps for some reason (rare), at least ensure the bundle itself contains no secrets — the rotate-everything-that-shipped principle applies. As a final layer, configure your CDN to refuse requests for `.map` files unless coming from your own dev tooling IPs.