Shipped with Lovable, v0, Bolt or Cursor? The 5 leaks to check before you share the link

You built something with Cursor, Lovable, v0 or Bolt, it works, and you're about to drop the link in a group chat or post it on X. Before you do: the same five leaks show up in the majority of AI-built apps we scan, and every one of them is visible to anyone who opens your site — no hacking required, just curiosity and browser DevTools.

None of these are your fault, exactly. AI coding tools optimise for "make it work," and "make it work" and "make it safe to share publicly" are different goals. Here's the pre-flight checklist.

The five leaks to check: (1) API keys in your JavaScript bundle, (2) a publicly served .env file, (3) an exposed .git folder, (4) source maps on production, and (5) missing security headers. Every one is visible to any visitor with browser DevTools — no hacking required. Here's how to check each in under a minute.

1. API keys in your JavaScript bundle

The leak: a secret key — OpenAI, Anthropic, Stripe sk_live_, a database credential — sitting in the code your browser downloads. You can't see it by reading your source in your editor, because it gets bundled into the JavaScript that ships to visitors. Anyone can open DevTools → Sources and read it.

Why it happens: the AI needed to call an API, put the call in the frontend because that was the quickest path to a working feature, and the key came along for the ride.

The check: open your deployed site, DevTools → Sources, and search the scripts for sk_, key, secret, token. Anything that looks like a real credential is a problem. The fix is to move that API call to a server route so the key stays on the server.

2. A publicly served .env file

The leak: your .env file — the one holding all your secrets — reachable at yoursite.com/.env. People (and bots) literally just type that URL.

Why it happens: a misconfigured static host, or the file getting copied into a public build folder. It's more common than it should be. (The full explanation of how this happens.)

The check: visit yoursite.com/.env in your browser. You should get a 404. If you see your environment variables, that's the worst-case leak — rotate every key in that file (runbook here) and fix the hosting config before anything else.

3. An exposed .git folder

The leak: your entire source-code repository — every file, every past version, every secret you ever committed and "removed" — downloadable from yoursite.com/.git/. Removing a secret from your current code doesn't remove it from git history, and if the .git folder is public, all of that history is public.

Why it happens: deploying by uploading your whole project folder (git metadata included) to a static host, instead of building and deploying only the output.

The check: visit yoursite.com/.git/config. A 404 is what you want. Anything else means your full history is exposed.

4. Source maps on production

The leak: source maps are files that reverse your minified production code back into your original, readable source — variable names, comments, file structure and all. Great for debugging, but if they ship to production they hand an attacker a perfectly legible copy of your app to study for other weaknesses.

Why it happens: the default build settings of many frameworks include them unless you turn them off.

The check: DevTools → Sources — if you can read your original, nicely-formatted code (not a minified blob), your source maps are public. Not catastrophic on its own, but it makes every other weakness easier to find.

5. Missing security headers

The leak: security headers are instructions your server sends the browser about how to protect your page — things like refusing to be embedded in a hostile iframe (clickjacking), or not letting injected scripts run. Missing them doesn't leak data directly, but it leaves the door open for a class of attacks that stronger headers would slam shut.

Why it happens: they're off by default almost everywhere and have to be added deliberately.

The check: this one is genuinely hard to eyeball — it means reading raw HTTP response headers and knowing which ones should be present. It's the least visible of the five and the most tedious to verify by hand.

The 15-second version of this whole list

You can walk through all five manually — and it's worth knowing how, because the knowledge is the point. But checking every one, by hand, every time you deploy, is exactly the kind of chore that quietly stops happening.

OpzyAI's free scan runs all five checks at once: paste your URL, wait about 15 seconds, get a plain-language report and a 0–100 score. No account, and it's passive — it only reads what your site already shows every visitor, and never attacks anything. If you live in Cursor or Claude Code, the MCP server runs the same check from inside your editor, so "is this safe to share?" becomes something you can ask before you ever post the link.

An honest caveat worth repeating: passing these five means you're not leaking the obvious things to the public internet. It doesn't mean your app is bulletproof — a passive check can't see your server-side logic or database rules. But the obvious leaks are the ones actually burning people right now. Start there.