Glossary

Source map

A source map is a JSON file that maps positions in a minified or compiled file back to positions in the original source, so that a debugger can show readable code and meaningful stack traces. It is indispensable during development. Published on a production server it can disclose substantially more than intended: when the map embeds the original sources, it hands over the readable codebase to anyone who fetches it.

How a map is found

A comment at the end of the minified file — `//# sourceMappingURL=bundle.js.map` — names the map's location.

A `SourceMap` HTTP response header does the same without modifying the file.

Browsers fetch the map only when developer tools are open, so a published map costs nothing in ordinary page loads and is invisible in normal traffic.

That invisibility is precisely why a map left on a production server tends to stay there for years.

The map may also be embedded in the file itself as a base64 data URI, in which case there is no separate file to remove and the bundle carries the sources directly.

What a map can contain

Always: the original file names and the position mappings, which reveal the project's directory structure.

Optionally, in `sourcesContent`: the complete original source text of every file in the bundle.

With `sourcesContent` present, fetching the map is equivalent to downloading the front-end source tree — comments, variable names, internal endpoint paths and all.

Anything a developer wrote into that code is included: commented-out experiments, internal URLs, feature flag names, and occasionally credentials that were never supposed to reach the bundle.

Why that matters and what it is not

The minified bundle was already public, so the logic was never secret. What the map adds is readability, which lowers the effort of studying it by a large factor.

The concrete risk is what the source contains beyond logic: internal hostnames, administrative endpoint paths, and secrets that should never have been in front-end code.

A secret in the bundle is a finding regardless of the map. The map makes it findable by reading rather than by searching minified text.

It is not an argument for not using source maps. It is an argument for choosing where they are readable from.

How to check and how to control it

Fetch the bundle and look for a `sourceMappingURL` comment, then fetch that URL. A 200 means the map is public.

Look for a `sourcesContent` key in the JSON; its presence is what turns a structural disclosure into a full source disclosure.

The usual arrangement is to generate maps, upload them to an error-tracking service, and not deploy them to the public server — keeping readable stack traces without publishing the source.

Where maps must be public, generating them without `sourcesContent` keeps the position mapping and omits the text.

Check CSS as well as JavaScript. Preprocessor source maps are generated by default in many build configurations and are forgotten more often than the script ones.

Frequently asked questions

Are public source maps a security vulnerability?
Not in themselves. They disclose information, and what that costs depends on what the source contains — internal endpoints, structure, or secrets that should not be in front-end code.
How do I keep readable stack traces without publishing maps?
Generate them at build time and upload them to the error-tracking service rather than deploying them to the public server.
What is sourcesContent?
An optional field embedding the original source text in the map. Without it, a map maps positions; with it, it contains the code.

Sources

Related

VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.

Scan a website