AI builders are very good at making things work. They’re less careful about who else can make them work. In 2025, a security researcher checked 1,645 apps from Lovable’s public showcase and found 170 whose databases anyone could read, including names, phone numbers, payment details and API keys. Later that year, the security company Escape scanned over 5,600 public vibe-coded apps and found more than 2,000 vulnerabilities and over 400 exposed secrets. The problems behind numbers like these are the ones below, and you can check each one yourself.
Everything below is for checking your own app. Please don’t try it on anyone else’s.
Can a stranger read your database?
If your app uses Supabase, and many AI-built apps do, you’ll find a key in the browser called the “anon” or “publishable” key. That’s fine. It’s designed to be public. What keeps your data private is Row Level Security: a switch on each table, plus rules saying who may read and change which rows. A table with Row Level Security off is readable by anyone who has that public key, which is everyone.
Try this: open your app in a private window without logging in, and see whether you can reach anything that belongs to a user. Then log in as a second test account and see whether you can see the first account’s data. Then ask your builder to check every table:
Prompt to paste into your builder
Check every table in my database. Make sure Row Level Security is enabled on all of them, and that each table has policies so people can only read and change their own rows, and only admins can see everything. List each table with its current rules before and after, and don’t delete any data.
Using a different database? Ask the same question: can someone logged out, or logged in as somebody else, read data that isn’t theirs?
Is a secret key sitting in your front end?
Some keys must never reach the browser: an OpenAI or other AI provider key, a Stripe secret key (they start with sk_), and Supabase’s service role key. Anything sent to the browser can be read by anyone who opens the developer tools, and leaked keys can be found and used quickly.
Prompt to paste into your builder
Find any secret keys in my front-end code, including AI provider keys, Stripe secret keys and the Supabase service role key. Move every call that uses them to a server function or edge function, store the keys as server-side secrets, and make sure none of them appear in the code sent to the browser.
If a secret key was ever visible, even for a day, create a new one in the provider’s dashboard and delete the old one. Hiding it now doesn’t help if someone already copied it.
What stops someone running up your bill?
If your app calls an AI model, every request costs you money. A bored visitor with a script can make thousands of them overnight. Set a monthly spending limit and billing alerts in your AI provider’s dashboard today. It takes two minutes. Then ask your builder to add rate limits (a maximum number of requests per person per minute) to the features that cost the most.
Are your admin pages really locked?
An admin page that’s just “not linked anywhere” is open to anyone who guesses the address, and /admin is the first thing people guess. Every admin page and action has to check, on the server, that the signed-in person is actually an admin.
Prompt to paste into your builder
Check that every admin page and admin action verifies on the server that the signed-in user has the admin role. Make sure nothing admin-only depends on hiding a button or a link.
Could you recover from a bad prompt?
One overconfident change can drop a table. Check whether your database plan includes automatic backups and how far back they go, and download a backup yourself before any big change. It turns a disaster into an annoying ten minutes.
Check again next week
AI builders rewrite code freely, and a fix from last week can quietly disappear in today’s change. Run through this list again after every big change, and once more before you share your app widely.