Source maps in production — what they leak and how to turn them off in Vite and Next.js

Your production bundle is minified — unreadable, you'd think. But if your build also ships source maps, anyone can ask for main-XYZ.js.map and get your original source back: file structure, comments, variable names, business logic. Browsers don't even need to be clever; DevTools reconstructs your src/ folder automatically.

AI builders and starter templates flip source maps on surprisingly often — for debugging convenience — and nobody flips them off before launch. It's one of our fifteen checks: source map publicly accessible. (Practical guidance, not legal advice.)

What actually leaks

• Your complete readable source — components, routes, API call structure, feature flags, half-finished admin panels.
• Comments — including the // TODO: fix this auth bypass variety, and sometimes credentials someone parked in a comment.
• Hardcoded values — API endpoints, internal URLs, and any secret that was compiled into the bundle. (A secret in frontend code is exposed with or without source maps — maps just remove the last bit of effort: admin key exposed in frontend code.)

Legally, shipping readable internals isn't automatically a GDPR violation — but it undercuts the "appropriate technical measures" argument of Art. 32, and it hands anyone probing your app a map. Literally.

Check your app in 30 seconds

1. Open your deployed app, DevTools → Network, reload.
2. Take the URL of any bundle, e.g. /assets/index-a1b2c3.js, and request the same URL with .map appended.
3. JSON with a "sourcesContent" field = your source is public. (Also look at the bundle's last line: //# sourceMappingURL=... tells browsers — and everyone else — where the map lives.)

Turning them off

• Vite — production builds default to *no* source maps. If yours ship anyway, someone set it; remove build.sourcemap: true from vite.config.* (or set sourcemap: false).
• Next.js — the browser-side default is off; make sure nobody enabled productionBrowserSourceMaps: true in next.config.js.
• Create React App — historically defaults to *generating* maps: build with GENERATE_SOURCEMAP=false.
• Hosting-layer fallback: if you can't touch the build, block *.map at the edge (Netlify _headers/redirects, vercel.json) — worse than not generating them, better than serving them.

If you want error monitoring with readable stack traces (the legitimate reason maps exist), upload maps directly to your error tracker (Sentry & co. support this) and keep them off the public server. You get the debugging benefit without publishing your source.

Common questions

Are source maps a real risk or a theoretical one?

Middle ground: they're not an exploit by themselves — they're reconnaissance gold. Combined with the findings that *are* exploitable (an open database, a service-role key), they shorten an attacker's path from hours to minutes. Cheap to fix, so fix it.

My app is open source anyway — do I care?

Then the source is public by choice and maps leak nothing new — turning them off is optional hygiene. The check matters for everyone whose code is *not* meant to be public, which is most commercial apps.

Do source maps slow my site down?

Not for users — browsers only fetch .map files when DevTools is open. The cost isn't performance; it's disclosure.

The rest of the launch pass

Source maps are one of the quick wins next to security headers (test yours: headers check) and the consent basics. Or run all fifteen checks in one pass — free, passive, nothing stored.

Related posts

• Is your Bolt.new app GDPR compliant? What to check before taking EU users
• Is your Lovable app GDPR compliant? The 15-point checklist
• anon key vs service_role key — the Supabase mistake that hands strangers your database