Exposed source maps: how to disable them in Vite and Next.js

What a public source map gives away

A source map is a .map file that links your minified JavaScript back to the original code. Most maps include the full original source, so anyone who downloads one can read your file and folder names, comments, internal API routes, feature flags and business logic as you wrote them.

A source map doesn't add new secrets on its own. Any key in your front-end code is already in the minified bundle, and the map just makes it easier to find. If a secret is in your client code, move it server-side and rotate it whether or not you have source maps.

How browsers find them

A built JavaScript file points to its map with a sourceMappingURL comment on its last line, or with a SourceMap response header. Browser developer tools follow that pointer automatically and show your original files in the Sources panel.

How to check your own site

Open your site, open the developer tools and look at the Sources panel. If you can see your original src folder with readable components, your source maps are public.

You can also open one of your JavaScript files directly and look at the last line. If it ends with a sourceMappingURL comment, open that URL. If a JSON file with a mappings field loads, the map is public. Only check sites you own.

Fix in Vite

Vite's build.sourcemap option is false by default, so a public map usually means it has been switched on. Open vite.config and remove sourcemap: true, or set it to false.

The 'inline' setting is worse than true, because it puts the whole map inside the JavaScript file itself. The 'hidden' setting still creates .map files but leaves out the comment that points to them. That stops browsers loading them automatically, but the files can still be downloaded if they are deployed, so only use it together with deleting the files after upload (see below).

Fix in Next.js

Next.js doesn't create browser source maps for production builds unless productionBrowserSourceMaps is set to true in next.config. When it is, Next.js serves the maps next to your JavaScript. Remove the option or set it to false.

Keep readable stack traces with Sentry

Error trackers such as Sentry need source maps, but they don't need them to be public. With Vite, set build.sourcemap to 'hidden', add the Sentry Vite plugin, and use its sourcemaps.filesToDeleteAfterUpload option so the .map files are uploaded to Sentry and then deleted before you deploy.

With Next.js, the Sentry SDK's withSentryConfig uploads maps during next build. Its sourcemaps.deleteSourcemapsAfterUpload option defaults to true, which deletes client-side maps in .next/static after they are uploaded.

Platform notes

Vercel: Protected Source Maps puts .map files behind Vercel Authentication, so only people with access to the deployment can load them and everyone else gets a 404. Vercel says it is on by default for new projects. Existing projects can turn it on under Settings, Deployment Protection. It doesn't cover maps inlined into JavaScript.

Lovable: older projects are React and Vite apps, and projects created from 13 May 2026 use TanStack Start, which also builds with Vite. If a public map turns up, ask Lovable to turn off production source maps in the Vite config.

Bolt: projects are standard framework projects such as Vite or Next.js, so the Vite and Next.js fixes above apply. On Netlify and other static hosts, the fix is to not generate or deploy public .map files.

What StackSiren checks (and doesn't)

StackSiren reads the end of each same-origin JavaScript file loaded by the page you submit, looking for a sourceMappingURL comment. It then requests up to three of those map URLs on your own domain. If one returns JSON with a mappings field, the finding is reported as low severity.

It doesn't check the SourceMap response header, maps inlined into JavaScript as data URLs, .map files that nothing points to (as with hidden source maps), or scripts that only load on other pages.