Lovable security audit: 10 Supabase checks before you launch

Lovable makes it possible to go from an idea to a working app with real users in days. Most Lovable apps use Supabase for the database, authentication and file storage. That architecture is sound, but it has one rule you cannot skip: the database is reachable from the browser, so the database itself must decide who sees what.

Why this matters

In 2025 a researcher scanned public Lovable apps and reported that more than 170 of about 1,600 exposed data through missing or weak row-level security. The issue was registered as CVE-2025-48757. Lovable has since added security checks, but the underlying rule has not changed: every table needs correct policies, and only you know what “correct” means for your data.

The 10 checks

1. RLS is enabled on every table

In the Supabase SQL editor, run:

select tablename, rowsecurity
from pg_tables
where schemaname = 'public';

Every row should show true. A table with RLS off is readable and writable by anyone holding your public key.

2. Policies restrict, not just exist

RLS with a policy like using (true) is the same as no RLS. Look for policies that tie rows to the user, such as auth.uid() = user_id. Have separate policies for select, insert, update and delete, and use with check on insert and update so a user cannot write rows in someone else’s name.

3. Test as two users and as nobody

Create two test accounts. Log in as user A and try to read, change and delete user B’s records through the API, not just the interface. Then try the same with only the public key and no login. This takes 20 minutes and finds most real leaks.

4. The service-role key is not in the frontend

Search your built JavaScript, your repository and its history for the service-role or secret key. It bypasses RLS completely. It belongs only in edge function secrets. If it was ever committed or shipped, rotate it in Supabase; deleting the line is not enough.

5. Storage buckets are private when files are private

Check every bucket. Invoices, ID documents and user uploads should be in private buckets, with policies on storage.objects that limit access to the owner, and served through signed URLs.

6. Edge functions check who is calling

Every edge function should verify the user’s token and check that the user may act on the requested record. Never trust a user_id sent in the request body. Allow CORS only from your own domains.

7. Views and database functions do not bypass RLS

Postgres views run with their owner’s rights by default, which can skip RLS. Create them with security_invoker = true. Functions marked security definer also run with elevated rights: keep them few, set a fixed search_path, and check permissions inside them.

8. Auth settings fit a real launch

Require email confirmation, limit redirect URLs to your own domains, set a sensible minimum password length, and turn on MFA for admin accounts. Remove test users and seed accounts before launch.

9. Paid and abusable endpoints have limits

Sign-up, password reset, email sending and any edge function that calls a paid AI or SMS API need rate limits. Otherwise one script can run up your bill or get your email domain blocked overnight.

10. Run the Supabase Security Advisor and check backups

The Security Advisor in the Supabase dashboard flags tables without RLS, risky views and functions. Fix everything it reports. Then check which backups your plan includes and whether you have ever restored one.

Order of work

Do 1–4 first: they decide whether your data is exposed today. Then 5–7, then 8–10. Write down what you checked and what you found; that short record answers the first questions any investor, customer or partner will ask about security.

When to get a second pair of eyes

If your app takes payments, stores personal data of EU users, or is about to raise money or sign a larger customer, an independent review is worth it. Our security audit for AI-built apps covers these checks and the rest of our 12-point list for AI-built apps, with a concrete fix for every finding.