Before you launch a Lovable app: a pre-launch security checklist

Lovable gets an app from idea to working product faster than anything before it. It also helps on security: it scans for common database problems before each publish and offers a deeper AI review of the code. Use both. They catch a lot, and Lovable itself says they can’t guarantee an app is secure.

The gap is in what a scanner can’t know: which data in your app is private, who should be allowed to do what, and what happens when someone uses the app in a way you didn’t plan. This checklist covers that part. Go through it once before launch, and again after any big change.

Database #

1. Row Level Security is on for every table. Tables created through SQL, which is how AI tools create them, don’t get it by default. The 10-minute Supabase check shows how to list them.

2. No private table has a rule that allows everything. A rule with using (true) on profiles, orders or messages means anyone can read them, RLS or not.

3. Users can’t promote themselves. If the profiles table has a role, is_admin or plan column and users may update their own row, they can change that column too, from the browser, in one request. Keep roles and paid status in a separate table that only server code can write, or restrict which columns the update rule allows.

select table_name, column_name
from information_schema.columns
where table_schema = 'public'
  and column_name ~* '(role|admin|plan|credits|verified|status)';

Compare the result with your update rules from the RLS check.

Keys #

4. No secret key in the frontend. Search the live app for sb_secret_ and service_role. If you find one, follow the first-hour plan for a leaked secret key.

5. No third-party secrets in the frontend either. AI, payment and email keys belong in server functions. Search for sk-, sk_live, re_ and check every environment variable starting with VITE_. How to move them to a server function.

Storage #

6. Personal files are in private buckets. Avatars can be public; IDs, invoices and contracts can’t. Each user should reach only their own folder. The Storage check.

7. Buckets have size and type limits. Otherwise anyone allowed to upload can store anything, at your cost.

Sign-in #

8. Email confirmation is on, unless you have a reason to turn it off. Without it, people can sign up with someone else’s address.

9. Redirect URLs are limited to your domains. In Supabase, under Authentication → URL Configuration, set the Site URL to your production domain and list only the addresses you use. Remove localhost and preview addresses you no longer need.

10. Sign-ups are closed if the app is invite-only. An internal tool with open sign-ups is a public app.

11. Every admin page checks the role on the server. Hiding a button is not access control. If a page or action is for admins, the data behind it must be protected by a rule or a server function that checks the role, so calling the API directly gets nothing.

Payments and functions #

12. Prices are decided on the server. The browser says what is being bought; the server looks up the price. A function that accepts an amount from the browser will eventually be sent 0.01.

13. Payment webhooks are verified by signature. A webhook endpoint that trusts any request lets anyone mark an order as paid.

14. Edge Functions check who is calling. Each function that reads data, spends money or sends email should verify the user and validate its input. One open function can undo every rule in your database.

Recovery #

15. You know how you would restore yesterday’s data. Open Database → Backups in Supabase and see what your plan includes; on lower plans it may be little or nothing. One wrong AI edit or a bad migration can delete a table. If the data matters, have backups you have actually restored once, to a test project.

After launch #

Security doesn’t stay done. Each new prompt can add a table without rules, a key in the wrong place or a function that trusts the browser. Two habits help:

• Run Lovable’s scan and the Supabase Security Advisor after every significant change, not only at launch.
• Ask the AI, in plain words, to explain the RLS rules and the functions it just created. If the explanation doesn’t match what you want, it is time to look closer.

If you would like a second pair of eyes before launch, our free Security Check goes through these points from the outside, read-only, and sends you the most serious issues in writing within 48 hours. When something needs fixing, the Security Fix takes care of it at a fixed price, quoted before any work starts.