Source Maps Exposed in Production

A source map is a file (app.js.map) that maps your minified production JavaScript back to the original source files, with readable names, folder structure and often comments. It's great for debugging. When it's public in production, anyone can open DevTools and browse your app's source as if they had your repo.

So should you use source maps in production? Usually generate them, but don't publish them. Upload them privately to your error tracker if you use one, and keep them off the public site.

The Pro Logica AI App Security Check looks for public source maps on your live app. Run the free check.

When exposed source maps matter (and when they don't)

Be realistic about the risk. Your minified JavaScript is already public, and a determined person can read it. A source map doesn't give anyone access they didn't have. It makes understanding your code much faster. That matters most when:

• Comments or dead code hold secrets or internal URLs. "TODO: remove test key sk_live_…" is more common than anyone admits.
• Your business logic lives in the client. Pricing rules, feature flags, admin route names and validation that only happens in the browser become easy to read and bypass.
• Your code is your edge. Readable source makes it easier to copy.

That's why the scan rates it low severity. It's not an emergency like a public .env file or an open database. It's an easy fix that removes free help for an attacker. If the map also reveals a key, the real problem is that key. See Exposed API key in frontend.

How to tell if your source maps are public

• Open DevTools → Sources. If you see your original src/ folder with .tsx files, maps are loading.
• Look at the last line of a production JS file. A //# sourceMappingURL=app-abc123.js.map comment points to the map.
• Request it directly: curl -I https://your-domain/assets/app-abc123.js.map. A 200 means it's public.

When you confirm you own the app, our scanner tries the .map URL for up to three of your JS files and flags it only when the response really is a source map. In public-sample mode, we only note a sourceMappingURL comment in JS we've already downloaded.

How to disable source maps in production

Vite (Lovable, Bolt, and many Cursor and Replit apps)

build.sourcemap defaults to false. Something in your config turned it on. In vite.config.ts:

export default defineConfig({
  build: {
    sourcemap: false, // or 'hidden' if you upload maps to an error tracker
  },
});

'hidden' still writes the .map files but leaves out the sourceMappingURL comment. The files are still uploaded with your build unless you delete them, though, so remove them in the build step after you upload them to your tracker.

Next.js (v0 and many Cursor apps)

productionBrowserSourceMaps defaults to false. Check next.config.js and remove productionBrowserSourceMaps: true unless you mean to publish browser maps.

Error-monitoring plugins

Tools like Sentry offer build plugins that upload source maps and then delete them from the build output. If you added one, check that the delete-after-upload option is on, then rescan.

Hosts without a build step you control

If your builder doesn't let you edit the build config, ask it in plain language: "Turn off production source maps in the Vite config and confirm no .js.map files are in the build output." The full report includes ready prompts for Lovable, Bolt, Replit, Cursor and v0.

Verify the fix

1. Rebuild and redeploy.
2. Look at your output folder (dist/ or .next/static). There should be no .map files, or none that get deployed.
3. Request an old .map URL. It should now return 404. Some CDNs cache old files, so purge the cache if you need to.
4. Rescan. The finding drops off your report.

What else to fix while you're there

Source maps usually travel with other build-config gaps. Check that no secrets use VITE_ or NEXT_PUBLIC_ prefixes, that /.env isn't served (Exposed .env file), and that your host sends security headers. In our passive check of 18 public showcase apps built with Lovable or Bolt, 18 of 18 had no Content-Security-Policy, and the average score was 76 out of 100. See the missing security headers checklist.

Related

• Cursor app security check · Replit app security check · v0 app security check
• Exposed API key in frontend
• More from Pro Logica: cybersecurity services · Run the free check on your app

FAQ

Should you use source maps in production?

Generate them if they help you debug production errors, but keep them private by uploading them to your error tracker and not deploying them. Don't publish them on your public site.

Are exposed source maps a security vulnerability?

They're an information leak, not a way in. They make it much easier to find real weaknesses, and to find any secrets that were left in comments. That's why we rate them low severity and recommend turning them off.

What does "source maps are enabled in production" mean in Lighthouse or other tools?

It means your production JavaScript references .map files. Some audits treat that as a good thing for debugging. From a security view, keep maps private, using 'hidden' maps uploaded to a tracker or none at all.

I set sourcemap: false but maps are still live. Why?

Old files may still be on your host or CDN from earlier deploys. Redeploy cleanly, purge the cache, and check that an old .map URL now returns 404.

Check whether your app publishes its source. Run the free AI app security check.