Example finding How it works Coverage PENTEST METHODOLOGY DOCS PRICING FAQ MCP CONTACT LOG IN SIGN UP →
SECURITY / TOOL

Source Map Exposure Checker

Paste a URL. The scanner follows every sourceMappingURL your bundles advertise, probes for a readable .git directory, and reports exactly how much of your original source a stranger can reconstruct.

/ INSTANT SCAN

CHECK FOR EXPOSED SOURCE NOW

Enter your URL - we fetch every .map file your bundles reference, probe common .git and build-artifact paths, and show which original files an attacker can reconstruct.

What is source map exposure?

A source map is a .map file that reconstructs your original files (component names, TypeScript types, comments, folder structure) from the minified production bundle. Browsers load it when DevTools is open so stack traces point at real lines.

If it is served from your public web root, anyone can read it. The bundle even names its location: minifiers append a //# sourceMappingURL= comment with the exact path.

A related failure is an exposed .git directory. If the deploy copies the project folder verbatim, /.git/ goes with it. Git holds full history, so a reachable .git exposes every commit, including the one that added a key and the later one that removed it.

Why this happens in AI-generated apps

AI coding tools (Lovable, Bolt, v0, Cursor, Replit) aim for a working preview. Development-mode settings carry into the deployed build: maps stay on because they were on while iterating, and the build flag never came up in the chat.

Deploy method matters too. A drag-and-drop upload, an rsync of the project folder, or a container that copies the working tree places .git, .DS_Store, editor backups, and full build output where a browser can reach them. Platform defaults that would catch this are skipped when someone deploys the project folder instead of the build directory.

Generated source also tends to be revealing: explanatory comments, inline endpoint lists, plainly named admin routes, and client-side permission checks that document how to bypass them. See source maps and .git exposed for the full pattern, and OWASP Top 10 for AI-generated code for how it combines with the other failure modes.

What the scanner checks

REFERENCED .MAP FILES

Every sourceMappingURL in your loaded bundles is followed and fetched to confirm it is publicly readable.

UNREFERENCED MAPS

Common map paths are probed even when the comment was stripped - removing the pointer does not remove the file.

INLINE BASE64 MAPS

Maps embedded directly into the bundle as a data URI, which no server rule can block.

EXPOSED .GIT

/.git/HEAD, /.git/config, and object paths - a readable repo means full commit history.

SECRETS IN SOURCE

Recovered original files are scanned for keys, tokens, and credentials that minification had obscured.

INTERNAL URLS AND ROUTES

Admin paths, staging hosts, and internal API endpoints named in the source but never linked from the UI.

REVEALING COMMENTS

TODO and FIXME notes describing known workarounds, disabled checks, and unfinished authorization logic.

STRAY BUILD ARTIFACTS

.DS_Store, editor backups, .bak copies, and build directories left in the web root.

How it works

  1. Load - we fetch your URL in a real headless browser and collect every script the page requested.
  2. Follow - each sourceMappingURL is resolved and fetched; common map paths are probed even when unreferenced.
  3. Probe - known exposure paths are requested directly, including .git internals and stray build artifacts.
  4. Reconstruct and scan - recovered original files are inspected for secrets, internal URLs, and revealing comments.
  5. Report - each finding lists the reachable URL, what it exposes, and the build or host change that closes it.

What each exposure gives away

Exposed path What an attacker gets Severity
bundle.js.map Full original frontend source: files, types, comments, structure High if source contains secrets or internal routes
Inline base64 map in bundle Same as above, and no server rule can strip it High - must be fixed at build time
/.git/HEAD, /.git/config Confirms a clonable repository and reveals the remote Critical - full history follows
/.git/ objects Every commit, branch, and deleted-but-committed secret Critical
/.env in web root Live configuration and credentials Critical - see the .env Exposure Checker
.DS_Store Directory listing of the deploy folder, including unlinked paths Medium - enables targeted probing
*.bak, *.old, *~ Prior versions of config or source, often pre-hardening Medium to high
Build directory in web root Unminified output, test fixtures, and dev-only pages Medium
/node_modules/ served Dependency inventory with exact versions for CVE matching Medium

Common fixes

  • Turn source map generation off for production builds, or generate them and upload them to your error-tracking provider instead of the web root. You keep readable stack traces without publishing your codebase.
  • If maps must ship to the web root, put them behind an auth-required path or a host rule that denies *.map to unauthenticated requests. Deleting only the sourceMappingURL comment leaves the file reachable.
  • Deploy the build output directory, never the project folder. Add .git, .env, .DS_Store, and backup patterns to .gitignore, .vercelignore, .dockerignore, and the equivalent for your host.
  • Add a host rule that denies every path beginning with a dot. It covers .git, .env, and any other dotfile.
  • Rotate every credential that appears in recovered source or Git history. Removing it in a later commit does not remove it from the objects an attacker already cloned.
  • Treat internal URLs and admin routes found in the source as public, and confirm each one enforces server-side authorization.
  • Re-scan after each deploy. A single “debug production” change can turn maps back on.

Common questions

What is a source map and why does exposing it matter?
A source map is a .map file that translates minified production JavaScript back into your original files - TypeScript, JSX, component names, comments and all. It exists so stack traces stay readable. When it is served publicly, anyone can reconstruct your entire frontend codebase from a browser, including internal API routes, feature flags, unreleased code paths, and secrets left in comments.
Is shipping source maps always a vulnerability?
Not by itself. Frontend code is never truly secret - a determined reader can decompile a bundle regardless. The real risk is what the original source contains that the bundle obscures: hardcoded endpoints, admin routes, TODO comments naming a workaround, test credentials, and the precise logic of client-side authorization checks. If your source is clean, exposure is low-severity. Most vibe-coded source is not clean.
What is an exposed .git directory?
If the deploy copies the whole project folder to the web root, /.git/ ships too. Because Git stores full object history, a reachable .git lets anyone clone your repository - every branch, every past commit, and every secret that was ever committed and later removed. It is strictly worse than a source map, because it includes history.
Doesn't a 403 on /.git/ mean I'm safe?
Not necessarily. Directory listing can be disabled while the individual object files remain readable. The scanner checks specific paths like /.git/HEAD and /.git/config rather than relying on whether the directory index renders.
How do attackers find these files?
They do not search - they follow. Every bundle that has a map ends with a sourceMappingURL comment naming its exact location. For .git, automated crawlers request the same handful of known paths against every host they see. Both are commodity scans that run continuously against the entire internet.
What does the scanner check?
Every sourceMappingURL referenced by your loaded scripts, inline base64 maps embedded in bundles, common map paths even when unreferenced, .git paths including HEAD and config, and stray build artifacts such as .DS_Store, backup files, and build output directories left in the web root.
Is the scan safe to run on production?
Yes. It issues ordinary GET requests for public paths, exactly as any crawler would. Nothing is written, no authentication is attempted, and recovered source is not retained beyond the report.
How do I stop shipping source maps?
Disable map generation in the production build, or generate them and upload them to your error-tracking provider instead of the web root. For .git, exclude it from the deploy and add a host rule that denies all dotfile paths. Then rotate anything the exposed source revealed - a secret that was public is compromised regardless of whether you saw it used.
/ NEXT STEP

Scan the full app, not just source

Recovered source is a map to the real bugs. The VibeEval agent tests the endpoints it reveals.

14-day free trial · No credit card · Cancel anytime

RUN FULL SCAN →