Lovable App Security Checklist: 10 Things to Fix Before Launch.

Lovable, Bolt, Base44 and similar tools are excellent at producing an app that works. They're less reliable at producing an app that is safe, because security problems don't show up when you click around as the owner. The app looks finished, the demo goes well, and the gap only appears when a stranger tries something you never did.

This checklist is written for Lovable apps backed by Supabase, the most common setup we see, but almost every point applies to any AI-built app. You don't need to be a developer to run most of these checks; where you do, the item tells you what to ask for.

1. Turn on database access rules for every table

Supabase lets your app talk to the database directly from the browser. That's safe only when Row Level Security (RLS) is enabled on every table and each table has policies saying who may read or change which rows. Without RLS, or with a policy like "allow everyone to select", anyone who opens your app's network requests can read the whole table.

We've seen this exact problem in a real audit: a table of chat leads with names, emails and phone numbers, protected by a policy literally named "Anyone can view responses". Open the Supabase dashboard, check that RLS shows as enabled on every table, and read each policy out loud. "Users can read their own rows" is the shape you want.

2. Test it as a second user

The fastest real-world test: create two accounts, add some data as user A, then log in as user B and try to see or change it. Try it through the app, and ask a developer to try the same requests directly against the API. If user B can see anything that belongs to user A, your access rules are wrong, no matter how the screens look.

3. Keep secret keys out of the front end

Your app's front end is public: anyone can read the code their browser downloads. The Supabase anon (publishable) key is designed to be there; the service role key is not, and neither are secret keys for Stripe, OpenAI, email or SMS providers. Search your project and GitHub repository for them. Any secret that was ever committed should be rotated, because deleting it from the code doesn't remove it from history.

Calls that need a secret key belong in a server function (for example a Supabase Edge Function) that checks who is calling before doing anything.

4. Don't protect pages only by hiding buttons

AI-generated apps often hide the admin menu from normal users and call it done. But hiding a button doesn't stop someone calling the same database query or visiting the same URL. Every sensitive action must be checked where the data lives: in RLS policies or in a server function that verifies the user's role.

5. Lock down your admin role

Check how the app decides who is an admin. If it's a field users can edit on their own profile, or a value stored in the browser, anyone can promote themselves. Roles should be stored where users can't change them and checked on the server for every admin action.

6. Make file storage private by default

Uploaded invoices, ID documents and photos often end up in a public storage bucket because that was the quickest way to make images show. Use private buckets for anything personal, give each user access only to their own files, and serve them through short-lived signed links.

7. Verify payments on the server

Never trust the price, plan or "payment succeeded" flag that comes from the browser. Payment status should come from your payment provider: for Stripe, a webhook whose signature your server verifies before it upgrades anyone's plan. Test what happens if someone changes the amount in the request, cancels halfway, or replays an old success message.

8. Check your login and sign-up settings

• Confirm email verification is on if your app relies on knowing who users are.
• Make sure password reset links expire and work only once.
• Restrict who can sign up if the app is internal (invite-only or a company email domain).
• Set allowed redirect URLs to your own domain only.

9. Validate input and add limits

Forms and AI features invite abuse: spam sign-ups, huge uploads, scripts calling your AI endpoint thousands of times on your bill. Add server-side validation, size limits and rate limits on anything that costs money or sends messages, plus a spending cap with your AI provider.

10. Know what happens when something breaks

Turn on database backups and test restoring one. Make sure error messages shown to users don't reveal table names, keys or stack traces. Set up basic error monitoring so you hear about failures before your customers tell you.

The 15-minute version

If you only do three things today: confirm RLS is on for every table with sensible policies, search your code for secret keys and rotate any you find, and test your app as a second user. Those three catch most of the serious issues we see in AI-built apps.

Want a second pair of eyes? We review and fix apps built with Lovable, Base44, Bolt and Replit: security, payments, integrations and launch. See our Lovable & Base44 development page, or read our comparison of AI app builders if you're still choosing a tool.