Your minified JavaScript is not protecting anything. If your source maps are publicly accessible, and they probably are, anyone can reconstruct your entire application source code in about thirty seconds.
Not fragments. The full thing. API routes, authentication logic, database queries, environment variable references. Sometimes hardcoded secrets that made it past code review. Sometimes LLM system prompts sitting in plain text.
Most teams do not know their source maps are public. Webpack, Vite, and Next.js all generate them by default.
How it works
A .map file is a JSON document that maps minified production code back to the original source. Your browser uses it for debugging. So can anyone else.
Take any JavaScript bundle on your site. Append .map to the URL. If you get a 200 response with valid JSON, your source code is public.
https://yourapp.com/static/js/main.a1b2c3.js.map
That file contains a sourcesContent field with every original source file that was bundled. Variable names, comments, internal logic, all of it. Minification is not security. It is compression.
What attackers find in source maps
This is not theoretical. These are patterns found in real scans:
- API keys and secrets hardcoded in configuration files or utility modules
- Internal API endpoints not documented publicly but fully visible in route definitions
- Authentication and authorisation logic including role checks, token validation, and session handling
- Database query patterns that reveal schema structure and field names
- LLM system prompts embedded in AI-powered applications, exposing the full instruction set
- Third-party service integrations with credentials, webhook URLs, and internal identifiers
An exposed source map does not just reveal how your application works. It reveals where it is weak.
The compliance angle
Source map exposure maps directly to findings under multiple frameworks:
- OWASP A05:2021 (Security Misconfiguration): Default build tool settings shipping debug assets to production
- SOC 2 CC6.1: Logical access controls failing to restrict access to sensitive system information
- ISO 27001 A.8.9: Configuration management not preventing exposure of development assets
If you are going through a SOC 2 examination or ISO 27001 certification and your source maps are public, that is a finding your auditor should be catching.
How to fix it
Block .map files at your CDN or web server.
nginx:
location ~* \.map$ {
return 403;
}
CloudFront: Add a behaviour pattern for *.map that returns a 403 response.
Next.js: Set productionBrowserSourceMaps: false in next.config.js. This is the default in recent versions, but older projects may have it enabled explicitly.
Vite: Set build.sourcemap to false or 'hidden' in vite.config.js. Hidden generates source maps for error tracking services but does not reference them in the bundle.
Webpack: Set devtool to false or 'hidden-source-map' in your production config.
After the fix, verify it. Request the .map URLs directly. If you get a 403 or 404, you are good. If you still get a 200, your CDN is caching the old files and you need to invalidate.
The real problem
Source maps are a symptom. The real question is: what else is your build pipeline shipping to production that it should not be?
Debug headers. Verbose error messages. Unprotected API documentation. Development endpoints left open. If your source maps are public, the rest of your production hygiene is worth questioning too.