Is your Lovable app secure? Lovable security checks before launch

Updated Oct 22, 20263 min read

Lovable can ship a working app in an afternoon. Lovable security tools help, since every publish runs a quick scan, but the same speed that gets you a UI and a Supabase backend also skips the boring security work. Check these yourself before strangers use your app.

Why Lovable security 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 exposed endpoints were reachable either way.

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.

What Lovable's security scan covers

Lovable's docs describe a Quick scan that runs on every publish. It checks database rules (tables without RLS, rules that let everyone through), known vulnerable npm dependencies and exposed MCP servers. A Deep scan reviews your app code for access control, open endpoints, injection and leaked secrets, but you have to start it yourself. Lovable's own docs say these tools "cannot guarantee complete security". We compare the scan with an outside repo review in Lovable security scan vs Leakcade.

Lovable security checklist before you launch

1. Check RLS on every table

   Open the Supabase dashboard and confirm RLS is enabled on every table your app uses.

2. Read each write policy

   For update and delete, avoid using (true), and for insert avoid with check (true) or a check that only asks for a login, unless the table is meant to be writable by anyone. A policy that only checks for a login isn't enough either.

3. Revoke grants anon doesn't need

   Signed-out visitors should only reach the tables that are meant to be public.

4. Keep secrets out of the frontend

   Search the client bundle and env files for service-role keys and API secrets. Lovable's docs say to keep them in Secrets and call them from Edge Functions. VITE_ values are public.

5. Check sessions on the server

   Confirm login-gated features check the session in an Edge Function or RLS, not only in the UI.

6. Test with your own anon key

   Call the REST API with a broad select while signed out and see what comes back. Then go through the rest of the vibe coding security checklist.

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

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

FAQ