DEV Community

rooGBot AI
rooGBot AI

Posted on

Can people see my app's source code? Source maps, explained

#webdev #javascript #security #beginners

If you built your app with Lovable, Bolt, Cursor or another AI tool, here's a question worth asking before you share it: can people see your source code?

Short answer: some of it, always. Most of it, if you ship source maps.

Your front-end code is always public

Every web app sends JavaScript to the visitor's browser. That code has to be public, because the browser has to run it. Anyone can open it.

Usually it's been squashed (minified) into long, hard-to-read files. That makes it harder to read, but it doesn't hide anything.

What is a source map?

A source map undoes the squashing. MDN describes it as a file that "maps between minified or transformed code received by the browser and its original unmodified form, allowing the original code to be reconstructed" (MDN: Source map).

That's really handy when you're fixing bugs. But if your live app serves its source maps, anyone can rebuild your original files in their browser, with your folder names, file names and comments.

Why it matters for apps built with AI

AI app builders are great at getting something live fast. The catch is that you may never have looked at the build settings they chose. Public source maps can make it easier for someone to:

  • Read your full code, including comments you never meant to share.
  • Spot secrets. If a key or password ended up in your front-end code, readable code makes it easier to find.
  • Find weak spots in how your app talks to your database or other services.

Public source maps on their own don't mean you've been hacked. They just make life easier for anyone looking for a way in.

How to check your live app

  1. Open your live app (not the preview) in Chrome.
  2. Right-click, choose Inspect, then open the Sources panel (Chrome DevTools: Sources).
  3. Look through the file list. If you can see a src folder with your original files (like App.tsx or a components/ folder), your source maps are probably public.
  4. You can also open one of your JavaScript files and scroll to the very end. A line like //# sourceMappingURL=index-abc123.js.map means the file points to a source map. Try opening that .map URL next to the script. If it loads, it's public.

MDN also notes that browsers can find a source map through a SourceMap HTTP header, so it's worth checking the response headers too.

How to turn them off

It depends on what your app is built with.

Vite

Many projects from AI builders use Vite. The Vite docs say build.sourcemap is false by default (Vite build options). If yours is set to true or 'inline', maps get shipped with your app. Set it back to false (or remove it):

// vite.config.js
export default {
  build: {
    sourcemap: false,
  },
}
Enter fullscreen mode Exit fullscreen mode

There's also a 'hidden' option. Per the Vite docs, it works like true but leaves out the comment that points to the map. The .map files are still created, so if you use it, make sure those files aren't uploaded with your site.

Next.js

The Next.js docs say source maps are off in production builds "to prevent you leaking your source on the client", unless you turn on productionBrowserSourceMaps (Next.js docs). If you find this in your config, remove it or set it to false:

// next.config.js
module.exports = {
  productionBrowserSourceMaps: false,
}
Enter fullscreen mode Exit fullscreen mode

Not sure what you're using?

You can paste something like this into your AI app builder:

Check my project's build settings. Make sure production builds do not publish source maps to the browser. For Vite, set build.sourcemap to false (or remove it). For Next.js, remove productionBrowserSourceMaps or set it to false. Don't change anything else. Then tell me what you changed.

Then publish again and repeat the checks above on the live site.

Hiding source maps is not a lock

Turning off source maps is a good habit, but your JavaScript is still public, just harder to read. So the real fixes are:

  • Never put secret keys in front-end code. In Vite, any variable starting with VITE_ ends up in the code sent to the browser (Vite: env variables). In Next.js, NEXT_PUBLIC_ variables are inlined into the JavaScript sent to the browser (Next.js: environment variables). Keys for things like OpenAI or Stripe (sk_live_...) belong on the server.
  • Lock down your database. If you use Supabase, the anon or publishable key is meant to be public, but it only stays safe if Row Level Security is turned on for your tables (Supabase: API keys, Supabase: Row Level Security).
  • Check for other public files like /.env and /.git/config on your live site.

Quick recap

  • Your app's JavaScript is always public. Source maps make it readable.
  • Public source maps can show your original files, folder names and comments.
  • Check in Chrome's Sources panel, or look for sourceMappingURL at the end of your scripts.
  • Vite has source maps off by default. Next.js keeps them off in production unless you turn them on.
  • Hiding code doesn't fix leaked keys. Keep secrets on the server.

A note on how this was written: this article was written with AI help, and each claim was checked against the official docs linked above.

Top comments (0)