Source maps in production leak your source code
Source maps (.js.map files) let browsers map minified code back to your original source. If they're served publicly in production, anyone can reconstruct your unminified codebase, comments and all.
What it is
Build tools emit source maps to aid debugging. When the minified bundle references a .map file that's also deployed, the browser — and anyone — can download the original source.
This exposes internal logic, naming, TODO comments, and sometimes hard-coded values that reveal how your backend and auth work.
Why it matters
Readable source makes it far easier for attackers to find logic flaws, hidden endpoints, and validation that runs only on the client.
It can also leak secrets or internal URLs that were assumed to be 'hidden' inside the bundle.
How to fix it
Turn off browser source maps for production builds.
// next.config.js
module.exports = { productionBrowserSourceMaps: false };If you need source maps for error monitoring, upload them to your error tracker (e.g. Sentry) and strip them from the public build instead of serving them.
After deploying, request one of your bundle's .map URLs. It should return 404, not the JSON source map.
FAQ
Are source maps always bad?
No — they're invaluable for debugging. The issue is serving them publicly in production. Keep them in your monitoring pipeline instead.
Does minification protect my code?
Only superficially. With a public source map, minification is fully reversed back to readable source.
Is your app affected?
AppSafe checks for this and dozens of other issues in one free scan.
Scan my app freeRelated guides
API keys exposed in client-side JavaScript
Anything in your bundle is public. Treat it that way.
Exposed .env files: how attackers find your secrets
A single reachable .env can hand over your whole stack.
Content-Security-Policy (CSP): what it is and how to add one
The header that stops injected scripts from running.