JavaScript Source Maps Left Public: Finding an Exposure Before Attackers Do

Minified JavaScript is hard to read on purpose: variable names are shortened, whitespace is stripped, and several files may be merged into one. A source map is the key that reverses that process, mapping each piece of minified code back to the original source file, line and name. Developers need source maps to debug production errors, which is why build tools generate them. The problem arises when the map file is published alongside the JavaScript on a public server, where anyone can download it and reconstruct the original sources. The JavaScript Source Map Exposure Checker examines the paths and references you paste in for source-map patterns and reports what it finds. It works on pasted input, not by probing live servers, and it does not download files or judge whether a particular map is sensitive; it flags the pattern so a human can decide.

What a public map reveals is often more than people expect. Original file names and directory structures show how a project is organised, original variable and function names reveal business logic, and embedded source content, when the map includes it, can reproduce the original code almost exactly. Even a map without embedded sources still gives an attacker the structure of the application, which speeds up the search for weaknesses. None of this means the application is broken, but it does mean that information the team thought was private is in fact public, and that gap deserves a decision rather than an accident.

How it works

A source map exposure usually takes one of two forms. The first is a separate .map file sitting next to the JavaScript file on the server, reachable by guessing its address from the script's address. The second is a reference inside the JavaScript file itself, a comment at the end pointing to the map, which advertises the map's location to anyone who reads the script. The checker looks at the pasted references for these patterns: a .map suffix, a sourceMappingURL comment, and paths that suggest a map file alongside a script. Finding a pattern in pasted text is a prompt to check the real deployment, not a verdict that the live server exposes anything, since only the deployment itself can confirm that.

The fix is straightforward once the exposure is confirmed. Remove the map file from the public server, remove or strip the reference from the published script, and keep maps in a private location accessible only to the debugging tools that need them, such as an error-tracking service with upload restricted to your team. Then rebuild or republish the script if the reference is baked into it, and confirm that the published files no longer mention a map. Simply deleting the map file while leaving the reference in place is only half a fix, since the reference still advertises that a map existed.

Where it goes wrong

The most common mistake is assuming that minification alone hides source code, and therefore treating maps as harmless. Another is shipping maps because the build tool generates them by default, without anyone deciding that publication was intended. A third is removing the map from one deployment while leaving it on a staging or old server that is still public, which preserves the exposure under a different address. Also avoid pasting internal file paths, credentials or private source code into any checker along with the reference; the checker needs the reference pattern, not your source.

Worked example

Worked example with sample values. Suppose you paste a sample list of 8 file references from a deployment inventory. The checker flags 3 of them as source-map patterns: 2 references ending in .map and 1 script containing a sourceMappingURL comment. That is 3 flagged out of 8, which is 3 divided by 8, or 37.5 percent of the sample references. Of the 3 flagged, 2 point to a public assets directory and 1 points to a private debugging directory, so 2 of 3 flagged references, about 66.7 percent, need action, while 1 is already correctly private. After remediation, a second run over the same 8 references flags 0, because the 2 public maps were removed and the script reference was stripped, leaving the 1 private reference as the only map-related entry and correctly unflagged as a public exposure. These are sample values for illustration, not results from a live server, and the counts show how a flagged pattern becomes a small, finite fix list.

Mistakes to avoid

One mistake is deleting maps entirely and then losing the ability to debug production errors; keep them privately instead of destroying them. Another is rotating a secret that was visible in a map without checking whether the map also exposed other secrets, such as API endpoints or internal hostnames, which need their own review. A third is fixing the main site while forgetting mobile or legacy builds, which often carry their own maps. Inventory every deployment that serves JavaScript, not just the flagship one.

Putting it into practice

Add a map check to the release checklist. Before each production release, list the JavaScript files being published, check the pasted references for map patterns, and confirm that no map file ships publicly and no script carries a map reference. Store maps privately with restricted access, and record where they live so the debugging workflow survives the fix. If a map was public, treat it as a disclosure: review what it contained, rotate anything sensitive it revealed, and note the exposure in your incident record. That routine keeps debugging possible without publishing your source.

Related tools and reading: the HTTP Headers Checker and the HTTPS Checker cover neighbouring checks that pair naturally with this one, and the guide at [/blog/http-security-headers-guide/] extends the same topic with further background and examples for readers who want to go deeper.

Key points

• A source map links minified code back to original sources
• A public map can expose file paths, names and logic
• Maps belong in private debugging storage, not on public servers
• Removing a map means removing the file and its reference

In short: A source map reverses minification, so a public map can expose original sources, structure and names. Check pasted references for map patterns, remove public maps and their references, and keep maps in private debugging storage. Confirm the fix by re-checking.

One habit ties all of this together: re-check after every change. A result is only as current as the input it was run on, so a fix, a redesign, or a new version of the underlying material deserves a fresh run rather than reliance on an old report. Keep the previous result alongside the new one, note what changed between them, and treat any new finding as a question to investigate rather than a verdict to accept or dismiss. That loop of checking, fixing, re-checking and recording is what turns a one-off test into a reliable routine, and it costs far less time than debugging a problem that a second check would have caught early.