Notes / Before launch
Is my Lovable app secure? A checklist before you launch
The problems that matter most in AI-built apps don't produce errors. The app works. It's just open. Here is how to check yours in an afternoon.
Lovable gets you from an idea to a working app remarkably fast. What it can't tell you is whether that app is safe to put in front of real users, because the most serious problems don't show up as bugs. Everything works. The data is simply more exposed than you think.
These are the checks I would run on any Lovable, Bolt or Replit app built on Supabase before launch. Most take a few minutes, and none of them require reading your whole codebase.
1. Check who can read and write your tables
This is the big one. Run the free self-check query in your Supabase SQL Editor. It lists every table, policy and storage rule that is more open than it should be. Fix anything marked critical before launch.
2. Make sure no secret key is in your live site
Open your live site, press F12, and search every loaded file for sb_secret_, service_role and sk_live_. None of them should appear. How to check properly, and what to do if one does.
3. Try to read another user's data
Create two test accounts. Signed in as the first, create something private, such as a note or an order, and copy its ID from the address bar or from the Network tab in developer tools. Then sign in as the second and try to open it using that ID. If you can see it, your policies check that someone is signed in, but not that the row belongs to them.
4. Check where your prices come from
If you take payments, the amount charged must be looked up on your server from your own database, never taken from what the browser sends. Otherwise anyone can edit the request and pay whatever they like. Find the code that creates the payment and check where the amount comes from.
5. Check your webhooks verify and deduplicate
Your payment webhook should reject requests without a valid signature, and cope with the same event arriving twice without doing the work twice. Verification and duplicate events each have their own note.
6. Review your authentication settings
Under Authentication in the Supabase dashboard, check three things. Email confirmation should be on unless you have a reason for it to be off. The Site URL and Redirect URLs should list only your real domains, so login links can't be pointed somewhere else. And if your plan offers leaked password protection, switch it on.
7. Look at any Edge Function that skips login checks
Edge Functions deployed with --no-verify-jwt accept requests from anyone. That is correct for a Stripe webhook, which checks Stripe's signature instead, but a hole for anything else. List your functions and make sure each of those does its own check.
8. Make sure your totals are complete
If a dashboard or export fetches rows and adds them up in the browser, it silently stops at 1,000 rows by default. Here is how to spot it and fix it.
9. Set up real email before launch
Supabase's built-in email sender is meant for testing and is heavily rate-limited. Before launch, connect your own SMTP provider under Authentication, and publish SPF, DKIM and DMARC records for your domain. Otherwise signup and password-reset emails go missing or land in spam, and it looks as if people just aren't signing up.
10. Know how you would recover
Check what backups your Supabase plan includes and how far back you can restore. Then delete your test accounts and test data, and remove any logging that prints personal information to the browser console.
What this won't catch
A checklist finds the common, visible problems. It won't find a policy that looks right but has a subtle gap, a race condition in your payment flow, or a feature that leaks data through a route nobody thought to test. That is the part an outside review is for.