AI app builders like Lovable, Bolt, Replit and Cursor are remarkable. You can go from idea to working product in days. But “it works” and “it’s safe” are different things, and AI tools are much better at the first than the second.
The good news: most serious problems in AI-built apps fall into a handful of patterns. Here are seven things to check before you put real customers and their data into your app. You don’t need to be technical to ask these questions. You just need to know what to look for.
1. Can anyone read your database?
Many AI-built apps use Supabase or Firebase. Both are excellent, but both rely on access rules that decide who can read and change which data. In Supabase these are called Row Level Security (RLS) policies; in Firebase, Security Rules.
If those rules are switched off or too loose, anyone who finds your app’s public address can read your whole database: customer names, emails, orders, everything. It’s one of the most common serious issues in AI-built apps.
How to check: In Supabase, open each table and confirm RLS is enabled and has policies. In Firebase, look for rules like allow read, write: if true, which means “anyone can do anything”.
2. Are secret keys hidden in your website code?
Apps talk to other services (payments, email, AI models) using API keys. Some keys are meant to be public. Others are secret and must only ever live on a server.
AI tools sometimes paste secret keys straight into the code that runs in your visitors’ browsers. Anyone can then copy them and use your accounts, and you pay the bill.
How to check: Search your code for words like sk_, secret, service_role or API_KEY. If a secret key appears in front-end code, treat it as leaked: rotate it (create a new one and delete the old one) and move it to the server. We wrote more about this in why AI-generated apps leak API keys.
3. Is every page and action protected by login?
It’s common for the buttons to be hidden from logged-out users while the actions behind them still work for anyone who knows the address. An attacker doesn’t click your buttons; they call your app directly.
How to check: Log out, then try to open pages like /admin or /dashboard directly. Better still, ask someone technical to check that the server checks who you are on every request, not just the screen.
4. Can users see each other’s data?
Even with login in place, a common bug lets User A see User B’s data by changing a number in the address bar (for example /invoices/124 to /invoices/125).
How to check: Create two test accounts. Log in as one, copy the address of something private, then log in as the other and paste it. You should see an error, not the first user’s data.
5. Are file uploads safe?
If users can upload files (photos, documents), check where they go. Uploads stored in a public bucket can be listed and downloaded by anyone, and unchecked uploads can be used to host malicious files on your domain.
How to check: Make sure upload storage is private by default, and that files can only be accessed by the people who should see them.
6. Is there anything stopping abuse?
Without limits, a single bot can create thousands of fake accounts, spam your contact form, or burn through your AI credits overnight.
How to check: Ask what happens if someone submits your sign-up or AI chat form 10,000 times. If the answer is “nothing stops them”, you need rate limits and, for AI features, a spending cap.
7. Are your building blocks up to date?
Every app is built on dozens of open-source packages. Old versions sometimes have known security holes that attackers scan for automatically.
How to check: Run npm audit (or ask your tool to) and look at anything marked high or critical.
What to do next
If you checked these and found nothing, great. You’re ahead of most. If you found something, or you’re not sure how to check, that’s exactly what our free audit is for. In 30 minutes we’ll look at your app with you and send you a short written summary of the top risks, in plain English.