I used Lovable, Bolt, v0 or Replit. Does this apply to me?

It applies to any workflow where the project folder is what gets deployed, which covers all of them at some point. The tool matters much less than what ends up in your web root, and that is what a scan measures instead of guessing from the platform.

My site is on Vercel or Netlify. Am I safe?

Mostly, and not entirely. Those platforms deploy build output by default, which is exactly the right behaviour. What they cannot help with is a secret that was committed into the code itself and ends up bundled into the JavaScript your visitors download, or a file you copied into the public folder by hand.

Is my API key really worth stealing?

The people looking for these are not choosing targets, they are scanning every address they can reach for a fixed list of filenames. A provider key gets used to run up charges on your account, and a database password gets used to take whatever is in the database. Neither requires anyone to care who you are.

What can the free scan actually see?

Everything your site shows the public: headers, TLS, the JavaScript libraries you load and their known CVEs, and the basics of how the site is configured. It does not go looking for files that are not linked from anywhere, because doing that to a domain without permission is probing rather than reading. That pass runs after you verify the domain is yours.

← Back to home

You built it with AI. Here is what to check.

AI tools take you from an idea to a live site fast. What they usually skip is checking whether the file with your database password should be public. So a lot of AI-built sites go live with those files open to anyone. This scan reads your site from the outside and shows you what is actually there, in plain words.

What AI-built sites tend to leak

The pattern is always the same file in the same place. Your project folder holds the code the visitor is meant to see and the settings only the server should read, and when the whole folder gets deployed, both go up together. Nothing warns you, because nothing is broken. The site works. The extra files are just sitting there next to it, one request away.

Four kinds of file account for almost all of it:

Environment files. .env, .env.local, .env.production. This is where the database password, the Stripe key and the mail credentials live, and it is the single most common thing to find open. (How the .env leak happens)
AI tool configs. .cursor/mcp.json, .mcp.json, .claude/settings.json, .aider.conf.yml and their siblings. They hold the provider key that bills to your card, and they name every server the tool was connected to, including internal ones. They start with a dot, so they are invisible in most file browsers and get deployed without anyone seeing them.
Private keys and cloud credentials. An id_rsa that got committed once, a service-account JSON, an .aws/credentials file. Any one of these is a login to something bigger than the website.
Forgotten backups and repository folders. config.php.bak from a quick edit, a database dump made before a change, or the whole .git folder if you deployed by cloning. (What an exposed .git folder gives away)

Why it happens

It is not carelessness, and it is not the tool being bad at its job. It is what happens when the review step is missing. A developer who has deployed a few sites has a habit: build output goes up, working directory does not. That habit is the only thing standing between a project folder and the internet, and it takes a couple of painful lessons to form.

Two specific things make it worse with AI tools. The first is speed. The gap between "it works" and "it is live" can be under a minute, and the checks that would normally happen in that gap have nowhere to fit. The second is that secrets get written down early. An assistant that needs a key to make something work will put it in a file so it works, and that file is now part of your project, part of your commits, and part of whatever gets deployed.

Once it is live, nothing tells you. There is no error, no warning and no sign on the page. The only way to know is to look at your site from the outside, which is exactly what a scan does.

Fixing the common ones

The order matters more than the individual steps. Rotate first, then close the hole, then stop it happening again. Rotating first is not a detail: for as long as the file was reachable, anyone could have taken a copy, and deleting it afterwards does nothing to a copy that is already gone.

Rotate every key the file held. New database password, new API keys, new tokens. Then check the billing and usage pages on each provider for calls you did not make.
Remove the file from what you deploy, and block dot-files at the web server so the next one cannot be served either.
Deploy build output, not your project folder. On Vercel, Netlify and most hosts this is the default; it stops being the default the moment someone uploads a folder over FTP or clones a repository into the web root.
Move secrets into your host's environment variables. They do the same job and there is no file to leak.
Add a deploy ignore list covering .env*, .git, dot-directories and backup extensions, so this is handled by the setup rather than by remembering.
Then check again. A fix nobody verified is a plan, not a fix.

If the scan finds something

A finding on this kind of site is almost never a subtle configuration argument. It is a specific file at a specific path, and the report gives you both, along with what to change and in what order.

Treat anything the file contained as public from the moment it went live, not from the moment you found it.
Fix the file first, then the deployment. Deleting one .env while the same process still ships your working directory means the next deploy puts it straight back.
If the AI tool committed the secret to your repository, it is in the history too, and history survives deletion. Rotate the key rather than trying to erase the commit.

See what actually made it to production

The free scan reads your site from the outside in about thirty seconds. No sign-up, no agent to install, nothing to change on your server. Verifying that the domain is yours unlocks the deeper pass that looks for the files above by name.

Scan your site, free

FAQ

I used Lovable, Bolt, v0 or Replit. Does this apply to me?: It applies to any workflow where the project folder is what gets deployed, which covers all of them at some point. The tool matters much less than what ends up in your web root, and that is what a scan measures instead of guessing from the platform.
My site is on Vercel or Netlify. Am I safe?: Mostly, and not entirely. Those platforms deploy build output by default, which is exactly the right behaviour. What they cannot help with is a secret that was committed into the code itself and ends up bundled into the JavaScript your visitors download, or a file you copied into the public folder by hand.
Is my API key really worth stealing?: The people looking for these are not choosing targets, they are scanning every address they can reach for a fixed list of filenames. A provider key gets used to run up charges on your account, and a database password gets used to take whatever is in the database. Neither requires anyone to care who you are.
What can the free scan actually see?: Everything your site shows the public: headers, TLS, the JavaScript libraries you load and their known CVEs, and the basics of how the site is configured. It does not go looking for files that are not linked from anywhere, because doing that to a domain without permission is probing rather than reading. That pass runs after you verify the domain is yours.