Verifiedapp Blog
Exposed Files

Source maps in production: shipping your source code by accident

· 2 min read
#exposed-files#frontend#source-maps

What a source map is

When you build a frontend, your readable code gets minified into a dense, unreadable blob for performance. A source map (bundle.js.map) is the reverse lookup: it tells the browser how to turn that blob back into your original files, with names and line numbers intact, so you can debug production issues comfortably. Useful — as long as only you can use it.

The accidental leak

The problem is that build tools generate source maps by default and deployment often ships everything in the output folder. So the .map files go live alongside the bundle, publicly reachable. Now the reverse lookup works for everyone: open dev tools on your site, head to the Sources panel, and your original folder structure and un-minified code appear. Minification was never security, and a public source map removes even that thin veil.

What an attacker actually gets

  • Your real source — readable, with original names, making it trivial to study your logic and spot weaknesses.
  • Comments — including the candid ones about workarounds, TODOs and where the bodies are buried.
  • Internal structure — module names, API routes, feature flags, the shape of your app.
  • Sometimes secrets — keys or tokens that were hidden inside minified code become plainly visible again.

How to check

Two quick ways. In the browser, open dev tools on your production site and look at the Sources panel — if you can see your original src/ tree and readable files, your maps are public. Directly, try requesting one of your bundle URLs with .map appended; if it downloads, it is exposed.

How to ship safely

You do not have to give up debugging — you have to stop publishing the maps:

  • Do not emit source maps to production, or emit them and delete the .map files before the deploy step.
  • Upload them privately to your error tracker (the common pattern): the tool gets the maps for readable stack traces, the public never does.
  • Block .map access at the server as a safety net, so a stray map still cannot be served.
  • Treat any exposed secret as leaked — if a key was visible through a public map, rotate it.

See whether yours are public

Source maps are easy to forget because everything still works whether they are public or not. An automated scan looks for the source-map references and the .map files an attacker would, and flags any that are reachable. Scan your site and make sure you have not published your source.

Related reading

FAQ

Are source maps a security risk on their own?
They do not create a vulnerability by themselves, but they hand attackers your readable source, comments and structure, which makes finding real weaknesses far easier — and they sometimes re-expose secrets hidden in minified code. Treat public maps as an information leak worth closing.
Can I keep source maps for debugging without exposing them?
Yes. The standard approach is to generate maps and upload them privately to your error-monitoring service for readable stack traces, then delete the .map files from the public deploy. You keep the debugging benefit without publishing your code.
How do I quickly tell if mine are exposed?
Open dev tools on your live site and check the Sources panel for your original file tree, or request a bundle URL with .map appended and see if it downloads. Either one means your maps are public.

Keep reading