How this check works
Scanaris takes the first scripts from your own domain linked by the home page, downloads each one and looks at the end for the //# sourceMappingURL=… comment left by the build tool. If it exists, it resolves that URL, requests the .map file and checks that it really is a source map (it contains the sources or mappings keys). Only then does it open the finding, at medium severity. Source maps embedded as data: do not count because they expose no separate file, and a .map that exists but no script points to is not detected this way either.
What an attacker does with this
With the .map and a free tool they rebuild your source code as you wrote it: variable names, comments, folder structure and, often, things you thought were gone. What usually shows up: internal and admin API routes, pricing or limit logic that can be bypassed from the client, comments like "TODO: remove this key" and features disabled but not deleted. It is not a breach by itself, but it turns a black box into a blueprint.
Why they get published by accident
Some templates enable maps for debugging and nobody disables them when going to production. In Vite, the build.sourcemap: true option generates them and adds the comment; in Next.js, productionBrowserSourceMaps: true; in Nuxt, sourcemap.client: true. In other cases they are generated by an error-monitoring integration that needs the maps and leaves them in the public folder instead of uploading them only to its service.
How to fix it
- Vite / Lovable / Bolt: in
vite.config,build.sourcemap: false. If your error tool needs them, use the service's plugin (Sentry and similar) that uploads them at build time and deletes them from the output. - Next.js:
productionBrowserSourceMapsisfalseby default; check that nobody changed it innext.config. - Nuxt:
sourcemap: { client: false }innuxt.config. - Block them on the server as a second barrier. In nginx:
location ~ \.map$ { return 404; }. On Vercel or Netlify it is enough not to generate them, because only what is in the output folder gets served.
If you prefer to keep them for debugging without publishing them, Vite's hidden option generates the files without the comment that links them; even so, keep them out of the public folder, because they remain reachable by anyone who guesses the name.
Check it is fixed
curl -s https://yourdomain.com | grep -oE 'src="[^"]+\.js[^"]*"' | cut -d'"' -f2 | head -3
curl -s https://yourdomain.com/assets/index-XXXX.js | tail -c 200
curl -sI https://yourdomain.com/assets/index-XXXX.js.map | head -1The second command must show no sourceMappingURL, and the third must return 404. If the first command lists no scripts, your page loads them another way; look in the browser tools, Network tab.
Frequently asked questions
Do I need source maps to understand production errors?
Yes, but they do not have to be public. Monitoring services accept the maps at build time and associate them with that release; the browser never sees them.
Are CSS maps a problem too?
Much less: they expose your original stylesheets, not logic. The scanner only reviews the JavaScript ones.
Why is it medium severity and not high?
Because a map gives access to nothing by itself; it makes finding other flaws easier. If the code also contains keys or unprotected admin routes, those are the serious findings, and Scanaris flags them separately.