R-SOU
source-map-explorer
Analyzes JavaScript source maps shipped to the client to reveal original, unminified source code and file structure.
OVERVIEW
source-map-explorer (github.com/danvk/source-map-explorer) was built as a bundle-size analysis tool for developers — it reads a JavaScript source map and visualizes how much of the final bundle size each original source file contributes — but the same source-map parsing is exactly what's needed to reverse a minified production bundle back into its original file structure and largely unminified source.
When a build pipeline accidentally ships .js.map files alongside the minified .js (a common misconfiguration, especially with older webpack/Vite defaults), anyone can pull the map and recover close to the original, human-readable source: variable names, comments, internal module boundaries, and sometimes hardcoded configuration or endpoints that were never meant to be readable client-side.
USE CASES
Practical use cases
- 01
Checking whether a production build exposes .js.map files that shouldn't be public.
- 02
Reconstructing original, unminified source and file/module structure from an exposed source map.
- 03
Reviewing recovered source for hardcoded secrets, internal endpoints, or comments not meant to ship.
- 04
Mapping a minified bundle's real folder structure to prioritize which original files to review manually.
QUICK START
When a production build exposes .js.map files, to reconstruct the original source tree and see far more of the application's internal logic than the minified bundle alone shows.
- Check whether the target serves .js.map files alongside its production JS bundles (often at the same path with .map appended).
- Confirm downloading and analyzing those files is within the authorized scope.
- Install source-map-explorer via npm.
- Run it against the downloaded bundle and its source map to visualize and extract the original structure.
- Review recovered source files for internal logic, endpoints, or secrets worth flagging.
npx source-map-explorer bundle.min.js bundle.min.js.mapBEFORE YOU RUN IT
What to check before running it
Exposed source maps are a configuration issue, not a vulnerability in the tool — the finding is the build pipeline shipping .map files to a public production origin, which should be reported and fixed at the build/deploy level.
Recovered source can include internal comments, TODOs, or hardcoded values the original developers assumed were private — handle and report that content under the same confidentiality rules as any other client-disclosed data.
Not every production app ships maps publicly; absence of a discoverable .map file doesn't mean the source can't be recovered by other means (deobfuscation, prettifying the minified bundle directly).