Public JavaScript source maps

Source maps published next to the bundles. They hand over the unminified source, comments and all.

• Help center

Modern front-ends ship minified bundles, and the build tool can write a .map file next to each one. The map links every line of the bundle back to the original source files — usually with their full content embedded, comments, internal paths and all. Browser developer tools load it to make debugging readable, but the same file is available to anyone who requests it.

Shipping source maps is not a vulnerability in itself: all JavaScript reaches the browser anyway. The risk is in what the original source reveals — hidden admin routes, feature flags, API endpoints, developer comments, occasionally a key that should have stayed on the server. That is why the row is a warning, not an error.

How SiteScan checks

The scan takes the first script the crawled pages load from the site itself and requests the same address with .map appended. It counts as published only when the answer is a 200 containing a real source map: JSON with "version": 3 and a "sources" list. The row then names the map.

How to fix it

Disable map generation for production (build.sourcemap: false in Vite, devtool: false in webpack), or generate "hidden" maps and upload them to your error tracker without deploying them. Alternatively block *.map at the server. Related: third-party scripts.