Source maps exposed: your app is publishing its original code

You scanned your app, and one line of the report says your original source code is published. Or someone technical pressed F12 on your site and told you your source maps are exposed. Either way it sounds bad in a specific, personal way: the thing you spent months building is apparently lying in the open, comments and all.

Both the alarming reading and the shrug are wrong. A source map is not a secret. It is a map (the name is literal) to where your secrets would be, if any were ever written into your code. Whether yours matters comes down to what is in there, and checking takes about 30 seconds.

Is it bad that your source maps are exposed?

It is worth fixing this week. It is rarely worth panicking about tonight.

What an exposed source map reveals is code, and your app already hands its code to every visitor, compressed into an unreadable block, but present, because that is how the web works. A patient stranger with the right tools could reconstruct a rough version of it from the compressed file alone. The map removes the patience requirement: with it, anyone who presses F12 reads your project laid out the way it looks in your editor.

Our scanner files a published source map as a medium, the middle of the severity scale, and that placement is deliberate. On its own, readable code is a loss of privacy: someone can study how your app works, read your half-finished features, borrow your ideas. Unpleasant, and for an app whose value is a clever prompt or an unusual flow, a genuine business problem. Not an open till.

The weight changes the day your code contains something that was never meant to be code. A key that runs as part of your app ends up in the compressed file too. A map makes it easier to find, but it was already published, and that is its own, bigger finding. Comments are different. Compression deletes them from what ships, so the map is the only public place a comment exists. A password in a commented-out line, a remove before launch note above the thing that never got removed, an internal address you jotted down next to the function that calls it. Those live nowhere a stranger can reach except the map.

What a source map actually is

It is the translation between the code your site ships and the code you wrote.

When your app is published, the build step compresses your code: every file squeezed together, every name shortened to a letter or two, every comment stripped, the whole thing on one enormous line. Browsers run that happily. Nobody can read it, including the tools that built it, which becomes a problem the moment something crashes and the error points at line 1, character 48,120 of a file no human has ever seen.

So build tools write a second file, the source map. It sits next to the compressed one (app.js gets app.js.map) and holds everything the compression threw away: your original files, their names, their folder layout, and every comment. The last line of the compressed file carries the map's address, and a browser fetches the map when its developer tools open. That is the whole design. It exists so an error can point at the code you actually wrote.

Two things follow from that design. Your visitors never download the map (a browser only asks for it when developer tools open), so a published map costs nothing, changes nothing on screen, and never announces itself. And anything that can open your site can fetch it, because the address is written in the page and there is no login in front of it. Whether the file is up there is a build setting, and from the outside, switched on looks exactly like switched off until someone goes looking.

How to check your app in 30 seconds

On your live app, the published address your users visit, not the preview inside your builder:

1. Open the app in Chrome, Edge or Firefox and press F12. This opens the browser's developer tools, the same panel a stranger would use.
2. Click the tab called Sources along the top of the panel.
3. Read the file tree on the left. Compressed code looks like one or two files with names like index-4f81ab2c.js. Source maps look like your project: a folder called src, files named after your pages and components, and code inside them you can actually read.

If you can open a file there and see your own comments, your source maps are published. The browser only draws that tree because it fetched the map from your live site, exactly the way anyone else's browser would.

If you would rather not poke around in panels, our free scan reads your live site from the outside and reports this check along with eight others: scan your app. It takes about 20 seconds and needs no account.

What a stranger can see, and what they cannot

Everything you wrote into the app itself, and nothing past it.

Published source maps reveal your frontend: your pages, your components, the logic that runs in the browser, the names of the routes your app calls, any prompt you wrote into the app, and every comment.

They do not reach your server. Code running in an edge function or a backend stays where it is. They do not open your database either. Whether a stranger can read your tables is decided by the rules on each table, not by your code being visible, and we measured that question separately across the same apps.

In practice, damage from a published map arrives as quiet reading rather than a dramatic break-in: someone studies your checkout logic for a way around it, or finds an admin route nobody ever linked to and tries it. Each of those becomes a problem only if the thing they found was unprotected. The map is a guide for a stranger; it is not itself the open door.

How often published source maps turn up

In August 2026 we scanned 30,998 live apps published from Lovable, Base44, Replit, v0 and Bolt. One in eight (13%) was serving at least one working source map.

We count a map only when it actually answers. The address at the bottom of a compressed file proves nothing by itself, because plenty of builds write the address and never upload the file; our scanner follows it and checks that a real map comes back. And where the check could not complete, we recorded that it could not complete. An app we failed to check is unknown, not clean.

Two other numbers from the same sweep put this one in its place. The leak owners are warned about most (a secret key in the page, the kind that ignores every database rule) turned up 3 times in those 30,998 apps. And a database table readable by any stranger turned up in more than half of the apps where we could complete that check. Exposed source maps sit between the two: far more common than the famous leak, far less directly damaging than the open table. Which is what a medium severity is trying to tell you.

How to turn source maps off in production

One build setting, then a redeploy.

If a builder made your app, tell it in plain words:

Disable source map generation for production builds and redeploy.

If you manage the code yourself, the setting lives in the build configuration. In a Vite project (which is what most Lovable and Bolt apps are underneath) that is build.sourcemap: false in vite.config; a Nuxt app has its own sourcemap option. Redeploy, then repeat the 30-second check: the readable file tree under Sources should be gone, and only the compressed names should remain.

Two follow-ups before you file this as done. Turning maps off does not recall the copies. Anyone who fetched your map while it was up still has your code as it was that day. So read your own source before you relax: if a key, a password or anything else that should not be public is written anywhere in it, rotate it now; removing the map closes the door on new readers, not on what was already copied. And the setting can come back: a template update, a regenerated config or a new deployment target can switch maps on again without you touching anything.

What to do right now

That last habit is the one that slips, because nothing looks different when the answer changes. Reeve Care re-runs this same scan against your live app on a schedule, this check included, and emails you when a result gets worse: what it watches and what it costs.

If you would rather close everything in one sitting, the 10-minute security checklist covers this alongside the other doors worth checking in a newly launched app.