Why apps built with AI end up with gaps
AI builders are good at making things work. Security is mostly about what should not work: a stranger reading someone else’s orders, a free user reaching a paid feature, a key that lets anyone spend your money. Unless you ask for those limits, the app usually doesn’t have them.
Most Lovable apps store data in Supabase. Supabase is safe when its access rules are set up, and wide open when they aren’t. That one setting matters more than any other.
The four things to check first
Can a stranger read your data?
Every table that holds customer data needs access rules (Supabase calls them row level security). Without them, anyone who opens your site can ask the database for every row. Our guide to row level security walks through it.
Are any secret keys in the website?
Your Supabase “anon” key is meant to be public. A “service role” key, a Stripe secret key (sk_live_…) or an OpenAI key is not. If one of those is in the code your visitors download, treat it as leaked.
Do paid features check who’s asking?
Hiding a button isn’t a lock. If the page hides “Export” for free users but the request behind it still works, a curious user can call it directly.
Can you undo a bad change?
Know how to roll back to the last version that worked, and keep a copy of your data. Lovable keeps a version history and can sync your code to GitHub; Supabase has backups on paid plans.
How to check your own app this afternoon
- Run a free scan of your live site. It shows secret keys left in the website, missing browser protections and loose login cookies, in plain words.
- Open Supabase → Advisors → Security Advisor. It lists tables without access rules and other risky settings.
- Sign up as two different test users. Logged in as one, try to open the other’s page or data by changing the address. You should get nothing.
- If your builder offers its own security check, run that too. Different tools notice different things.
When to ask an engineer
A scan only sees the outside of your app. It can’t tell whether your database rules are right, whether payments can be faked, or whether one user can reach another’s data through your app’s own requests. Those need someone reading how your app actually works.
It’s worth it before you take payments, before you store anything personal (health, finance, children’s data), or when you’re about to put the app in front of a lot of people.