Source Map Leak Checker

Paste your site's URL, or a list of specific JS file URLs. This reads each script's own sourceMappingURL comment, fetches the map it points at, and names which ones are publicly readable — and whether the map embeds full original source text or only file paths. See how source maps leak in production for background. Only run this against a site you own or are authorised to test.

Run the check

Enter a page URL or one or more script URLs, then click Check.

Prefer a CLI, or hit a CORS wall in the browser?

Most sites don't send permissive CORS headers on their main HTML document, so a browser tab often cannot read a cross-origin page's HTML at all — you'll see a generic network error with no HTTP status. Static JS/CSS assets on many CDNs and static hosts are more often served with permissive CORS, so pasting explicit script URLs above has better odds than a bare page URL. The CLI has no such restriction and is the one path guaranteed to complete: 

node check.mjs https://example.com/ --json
node check.mjs --script https://example.com/static/main.js --json

Get check.mjs, probe.mjs, and analyze.mjs from the repo — exit code 1 if any script's map is exposed, so you can gate a deploy on it.

Common questions

What is a source map, and why would it be a problem?

A source map is a file (usually named <script>.js.map) that maps a minified, bundled production script back to its original, unminified source files -- so a browser's devtools can show you readable code and real file names while debugging a live site. Most bundlers (webpack, esbuild, Vite, Rollup) can generate one automatically. The problem is that a source map with sourcesContent set doesn't just map locations back to file names -- it embeds the entire original, unminified source text of every file, including comments, internal variable and function names, and anything that was only removed by minification rather than deliberately kept out of the client bundle.

Isn't this exactly what source maps are for -- readable code in devtools?

Yes, for a developer working on their own local build. The exposure is specifically about a production deployment: if the .map file is left publicly reachable on the live site, anyone who opens devtools (or just requests the .map URL directly, whether or not they open devtools) can read it -- not just the site's own developers. Bundler docs generally recommend either omitting the sourceMappingURL comment in production, restricting access to the map file at the server/CDN level, or using a 'hidden' source map mode that uploads the map to an error-tracking service (for real stack traces) without ever referencing it from the shipped script. See how source maps leak in production for the common ways this happens and how to fix each one.

What can someone actually learn from an exposed map?

It depends on whether the map carries sourcesContent. Without it, an exposed map still reveals the original file and folder structure of the app -- useful reconnaissance about what framework and internal module layout is in use. With sourcesContent present, it hands over the complete original source: internal comments, business logic, API endpoint paths that were only referenced by variable name in the minified bundle, and occasionally a hardcoded value (a test key, an internal URL) a developer never meant to ship in readable form.

Is it safe to point this at a URL?

This tool sends only ordinary GET requests to the page and script/map URLs you name -- the same requests your own browser already makes when you load the page, and it never writes or submits anything. It does not upload the URL, the scripts, or anything they contain to our servers when run in the browser; every request goes straight from your browser to the target. Still, only run this against a site you own or are authorised to test, the same caution you would apply to any request tool aimed at someone else's server.

Does a clean report mean my site is safe?

It means the scripts this run could check either had no source map reference or had one that was not publicly readable at the time of the check. It does not check CSS source maps, inline (non-external) scripts, JS loaded by dynamic import after the initial page load, or anything not reachable from the page or script list you gave it. Treat a clean report as evidence about the scripts this run actually saw, not a full audit of the site. See how this compares to checking devtools by hand.