Is your Lovable app secure? What to check before you launch

Lovable can ship a working app in an afternoon. The same speed that gets you a UI and a Supabase backend also skips the boring security work. Here's what to check before strangers use it.

Why this matters

In March 2025, researcher Matt Palmer scanned 1,645 Lovable apps and found 303 exposed endpoints across 170 of them, about 10.3%, where Row Level Security was missing or too weak. That research led to CVE-2025-48757, which covers insufficient RLS in Lovable-generated apps through 2025-04-15. Lovable (listed as the Supplier on the CVE) disputes it: each customer is responsible for protecting their own app's data. The dispute is about who owns the label. The exposed endpoints were still reachable.

What goes wrong

Most Lovable apps use Supabase. The public REST API ships with the anon key. When RLS is off or a policy is too open, an attacker can change a request, for example by adding ?select=*, and pull rows they shouldn't see. The pattern is the same one we cover in Supabase RLS mistakes: public endpoint + anon key + weak policies.

Lovable's own security best practices say to review RLS, keep secrets out of the frontend, put auth and validation on the server, and use Edge Functions when you need credentials. That checklist exists because the default path is easy to ship without those pieces.

Checklist before you launch

1. Open the Supabase dashboard and confirm RLS is enabled on every table your app uses.
2. Read each policy. For insert, update and delete, avoid using (true) unless the table is meant to be writable by anyone.
3. Revoke grants anon doesn't need.
4. Search the client bundle and env files for service-role keys, API secrets and anything that belongs only on a server or in an Edge Function.
5. Confirm login-gated routes actually check the session on the server, not only in the UI.
6. Try your own anon key against the REST API with a broad select and see what comes back while signed out.

Fix prompt you can paste

This app was built with Lovable and Supabase. Review every table and policy:
enable RLS where it's missing, replace write policies that use (true) with
ownership checks on auth.uid(), revoke anon grants that aren't needed, move
any secrets out of the frontend into Edge Functions or server env, and list
what I should re-test with the anon key while signed out.

Further reading

Sources

1. Matt Palmer: CVE-2025-48757
2. Matt Palmer: Statement on CVE-2025-48757
3. NVD: CVE-2025-48757
4. Lovable docs: Security best practices
5. Leakcade: Supabase RLS mistakes