Guide · Ready to launch?
Vibe coding security checklist: 10 checks before you launch
Check these ten things before you launch an app built with an AI tool. The first five are in the order we found them most often, when we checked 50 real apps built with Lovable and Bolt in October 2026. Each comes with the words to paste into your tool, so you never have to open the code.
The five we found most
Outside code with known faults is updated
Every app is built partly from other people’s code. Some of those pieces have faults that were found and fixed in a later version, and the fix only reaches you when the app is updated. This was the most common problem we found, by a distance.
Measured: 32 of 47 apps we read had at least one.
Ask the tool that built your app:
Update the packages in this project that have known security problems to versions where they are fixed. Do not change anything else. Tell me which ones changed.
No secret key is in your code
Keys for payments, AI, email or your database admin must live on the server. In the code the browser downloads, or in a public repository, anyone can copy them and use them as you. Some keys are meant to be public; our guide to exposed keys shows which, and what to do if a secret one got out.
Measured: 18 of 47 apps we read had a key or password in the code.
Ask the tool that built your app:
Find every secret key in this project, including in old commits. Move each one into server side environment variables that never reach the browser, and list every key you moved. Keep only keys that are meant to be public in browser code. Tell me which keys were ever committed, because those must be replaced, not just moved.
Nobody can run up your bill
AI answers, text messages and emails cost you money each time. If a stranger can trigger them with no sign in and no limit, one person can send a hundred thousand overnight, and the bill is how you find out.
Measured: 17 of 47 apps we read had a paid service anyone could call without limit.
Ask the tool that built your app:
Every call to a paid service (AI, text messages, email) must go through my server, require the visitor to be signed in, and have a limit per person per day. List each one and its limit.
What visitors type cannot reach anything dangerous
Whatever someone types into a box on your site must be treated as words. When it is pasted straight into a database request or a page, a visitor can turn it into an instruction your app will follow.
Measured: 13 of 47 apps we read let typed input reach somewhere it could do harm.
Ask the tool that built your app:
Make sure nothing a visitor types is ever pasted directly into a database query, a command or the page’s HTML. Use the safe built in way of passing values for each one, and list every place you changed.
Your database is not readable by strangers
Apps built on Supabase hand every visitor a public key. That is fine only if every table has a rule about who may read it. If Supabase’s Security Advisor says “RLS disabled in public”, a table has no rule at all.
Measured: 1 of the 6 databases we could test was readable by a stranger (a small sample: most apps had no site we could reach).
Ask the tool that built your app:
Turn on row level security for every table in the public schema of my Supabase database, and add rules so signed in users only see their own rows and visitors only read tables meant to be public. List every table and its rule.
Five more worth checking
Our study could not measure these from the outside, so they have no number. They are real, they cost money when they go wrong, and our checker looks for each of them.
One customer cannot see another customer’s data
The most damaging leak needs no attacker: a signed in customer opens a page and sees everybody’s orders, because the rule said “anyone signed in” instead of “only the owner”. How we check for it.
This one was not measured in our study; it is one of the checks GuardCue runs.
No private file is served to the public
A settings file full of passwords, or the whole history of your code, sometimes ends up downloadable from your web address. It hands a stranger the keys to everything at once.
This one was not measured in our study; it is one of the checks GuardCue runs.
Payments are switched to the real keys
Payment companies give you practice keys and real keys. An app built quickly starts on the practice ones, and the checkout keeps working and the emails keep arriving while no money moves. Nobody gets an error; the bank account just stays empty.
This one was not measured in our study; it is one of the checks GuardCue runs.
Your app checks that a “payment received” message is real
When someone pays, the payment company tells your app so, and the app hands over what they bought. If the app does not check that message really came from the payment company, anyone can send it themselves and take the goods without paying.
This one was not measured in our study; it is one of the checks GuardCue runs.
You could get your data back
A bad change, a wrong delete, or your own AI tool getting it wrong can wipe a table. Check that backups are on and that you know where to restore from, before you need to.
This one was not measured in our study; it is one of the checks GuardCue runs.
Then check again after every change
Most of these arrive with a change, not on launch day: a new feature, a new table, a new paid service. Run through the list again whenever the app grows, or let a checker do it for you.
Where the numbers come from, how the 50 apps were chosen and what the counts cannot tell you is all on the study page.
GuardCue runs these checks for you and explains what it finds in plain English, for the person who built the app rather than for a developer. Check your site, free.