Built your site with AI? A security checklist for vibe-coded sites
AI builders like Lovable, Bolt, Replit and v0 let anyone ship a real app in a weekend. The catch: they often leave the security switched off by default. Here is what to check, in plain English, before your customers find the gaps.
"Vibe coding" means describing what you want to an AI tool and letting it build the app for you. It is genuinely brilliant for getting a working product in front of people fast. But there is a pattern worth understanding: the AI writes the part your visitors see, the screens and the buttons, and connects it to a database and a few services. The security of that database, those services and the keys that connect them is left to default settings, and the defaults are usually wide open. The site looks finished, so most people launch without ever turning the locks on.
None of this means your tool is bad or that you did something wrong. It means there is a short list of settings to check. Here it is, most important first.
1. The big one: your database left open to everyone
Most AI-built apps store their data in Supabase or Firebase. Both are excellent, and both ship with a public key that is meant to live in your site's code, in the browser, where anyone can read it. That key is safe only if you have also turned on the rules that say who is allowed to read each piece of data.
On Supabase those rules are called Row Level Security (RLS). On Firebase they are security rules. When they are off, which is the default while you are building, anyone who opens your site can take the public key and quietly download your entire database: every customer name, email, order and message. No login, no hacking, just a few lines anyone can run from their own browser. This is the single most common and most damaging mistake in AI-built sites.
How to check: our free website check recognises when your site runs on Supabase or Firebase. The in-depth audit goes further and safely tests, using only your own public key, whether each table or collection answers to the public, reading only a count, never your actual data.
How to fix: turn on row-level security (Supabase) or security rules (Firebase) for every table, then add a policy for each one that says who may read and write it. Your AI tool can help you write them once you ask for them by name.
2. Secret keys left in your code
There are two kinds of key. Public keys (a Supabase anon key, a Firebase web key, a Stripe publishable key) are meant to be in the browser and are fine there. Secret keys are not: a Stripe secret key, an OpenAI or Claude API key, a Supabase service-role key, a database password. These bypass every rule you set, and if one is sitting in your public code, anyone can copy it and act as you.
They end up there in two ways: typed straight into the code to "make it work", or through a common setup mistake that bundles your whole list of environment settings, secrets included, into the file the browser downloads.
How to check: the free website check reads your site's public code and flags secret keys it finds, including the AI-provider and database keys AI tools most often leak. It deliberately ignores the public keys that belong there, so it does not cry wolf.
How to fix: move secret keys out of the browser and onto a server (a serverless function is fine), keep them in server-only environment settings, and change any key that was ever exposed, because it has to be treated as known.
3. AI running on your bill
If your app talks to OpenAI or Claude, check where it does so. When the call is made straight from the visitor's browser, the key it uses reaches that browser too, even if you fetch the key at the last second. Anyone can open the developer tools, lift it, and run up your AI bill, which can reach hundreds of dollars overnight.
How to fix: make AI calls from your own server, never the browser. The browser asks your server, your server calls the AI with the key, and the key is never exposed.
4. Your source code left downloadable
Many build tools can publish "source maps", files that let anyone reconstruct your original code from the live site. Handy while developing, risky in production: they can reveal how your app works, internal addresses and the occasional forgotten key.
How to fix: turn off source maps in your production build. It is usually a single setting.
5. Files anyone can browse
Supabase and Firebase can also store uploaded files. The same lesson applies: if the storage rules are open, anyone can list and download everything in the bucket, including files that were never meant to be public.
How to fix: set storage rules so only the right people can list and read files, and keep anything private out of public buckets.
6. An admin page is not a lock
Hiding the "Admin" button, or putting the admin screen on a secret address, feels like security but is not. Anyone can still send the delete-everything request directly if the database allows it. The only real lock is at the data layer: the same row-level security and rules from point 1 decide what each person can actually do, button or no button.
Check your own site in about a minute
You do not have to guess. Our free website check reads your site the way any visitor can, tells you if it is built on Supabase, Firebase or with an AI tool, and flags any secret keys left in the code, with no sign-up. The in-depth audit then safely tests whether your database and files are actually open, and gives you a plain-English list of exactly what to fix and how. Everything is read-only; nothing on your site is ever changed.
Common questions
Is vibe coding safe?
Building with an AI tool is perfectly safe in itself. The risk is that these tools write the part visitors see and leave the security of your database, keys and files switched off by default. Those settings are yours to turn on, and most people never do because the site looks finished without them.
Does using Lovable, Bolt or Replit mean my site is insecure?
No. The tools are fine. The common problem is the default settings they ship with, mainly a database that anyone can read and keys left in the public code. Once those are locked down, an AI-built site can be just as secure as any other.
I am not technical. Can I check and fix these myself?
You can check in about a minute with our free website check, which recognises sites built on Supabase or Firebase and finds keys left in the code. Some fixes, like turning on row-level security, are a few clicks; others need a developer. The in-depth audit tells you exactly what is open and how to close it, and if you would rather not deal with it, we can.