Are Your Source Maps Leaking Your Code?

The short version

Source maps are files that map your minified, bundled JavaScript (or CSS) back to the original source code. They're incredibly useful for debugging. They're also a security concern if you ship them to production, because anyone can use them to read your original, unminified code.

Why source maps exist

When you build a modern web app, your code goes through a pipeline: TypeScript gets compiled, modules get bundled, code gets minified. The result is something like this:

var a=function(t){return t.map(function(n){return n*2})};export{a as d};

Good luck debugging that. Source maps solve this by providing a mapping between the minified code and your original source. When you open DevTools, the browser uses the source map to show you the original file, with original variable names, comments, and line numbers.

The source map is referenced at the end of your JavaScript file:

//# sourceMappingURL=app.js.map

The MDN source maps documentation covers how browsers discover and use them.

The security problem

If that .map file is publicly accessible on your server, anyone can download it and reconstruct your original source code. That includes:

• Business logic: Your pricing calculations, feature flags, admin checks.
• API endpoints: Every endpoint your frontend calls, including internal ones.
• Comments: Developer notes, TODO items, sometimes credentials or keys left in comments.
• Application structure: How your app is organized, which libraries you use, how authentication works.

This gives attackers a detailed map of your application. Instead of reverse-engineering minified code, they can read your source like a book and find vulnerabilities much faster.

How to check if you're exposed

1. Open your site and look at the page source or the Network tab in DevTools.
2. Find a JavaScript file and open it.
3. Scroll to the bottom. Look for //# sourceMappingURL=....
4. Try loading that .map URL in your browser.
5. If it returns a JSON file, your source maps are public.

How to fix it

Option 1: Don't generate source maps for production.

Most bundlers have a config option:

// Webpack
module.exports = {
  devtool: false, // No source maps in production
};

// Vite
export default {
  build: {
    sourcemap: false,
  },
};

Option 2: Generate them but don't serve them publicly.

Upload source maps to an error tracking service (like Sentry) but don't deploy them to your web server. This gives you debugging capability without public exposure.

Webpack can generate hidden source maps that omit the sourceMappingURL comment:

module.exports = {
  devtool: 'hidden-source-map',
};

Option 3: Block access at the server level.

Configure your web server or CDN to return 403 for .map files:

# Nginx
location ~* \.map$ {
  return 403;
}

The vibe coding angle

If you scaffolded your project with a tool like Bolt.new, create-react-app, or Vite's default template, source maps are probably enabled by default. The defaults are optimized for developer experience, not production security.

Before you deploy, check your build output. Look for .map files. If they're there and your hosting serves them, your source code is public.

What about CSS source maps?

CSS source maps (.css.map) are lower risk because CSS is already visible to users. But they can still reveal your Sass/SCSS file structure and organization, which gives attackers information about your build setup.

Check your site

Want to know if your site has this issue? Scan it now and find out in 60 seconds.