Lovable makes it fast to go from an idea to a working app, and most Lovable apps store their data in Supabase. Speed is the point, but it means security settings are easy to miss. Lovable’s own security documentation says its scanners “cannot guarantee complete security”. This checklist covers what to verify before you share your app with real users.
Is a Lovable app secure by default?
Not completely. Lovable runs a Quick scan automatically when you open the publish dialog. According to Lovable’s documentation, it looks for:
- database tables without row-level security
- access rules that allow everyone
- leaked-password protection being turned off
- known vulnerabilities in npm dependencies
- an MCP server exposed without authentication
A separate Deep scan goes further, covering access control, abusable endpoints, injection, leaked secrets, payments, authentication and exposed personal data. It does not run on its own: you start it from the Security view. Lovable is clear that these tools “do not replace a thorough security review”, and it recommends a professional review for apps that handle sensitive data.
What was CVE-2025-48757?
CVE-2025-48757 was published in the US National Vulnerability Database on 30 May 2025 with a critical score (CVSS 9.3). It describes insufficient row-level security policies in apps generated by Lovable up to 15 April 2025, which could let unauthenticated attackers read or write database tables. The record is marked disputed: Lovable’s position is that each customer is responsible for protecting their own application’s data.
Whichever side you take, the practical lesson is the same. The database rules in your Lovable app are your responsibility, so check them yourself.
The checklist: 9 things to verify before launch
1. Row-level security is on for every table
Supabase’s guidance is direct: “Enable RLS on every table in an exposed schema.” Once RLS is on, the public API returns no data from that table until you add policies that allow it. In the Supabase SQL editor, this query lists tables in the public schema that still have RLS off:
select tablename from pg_tables
where schemaname = 'public' and rowsecurity = false;An empty result is what you want.
2. No policy lets everyone in
RLS that is switched on but paired with a policy like using (true) protects nothing. This lists policies whose rule is simply “true”:
select tablename, policyname, cmd from pg_policies
where qual = 'true' or with_check = 'true';Some public read access can be intentional, for example a list of published blog posts. Anything containing user data, orders or messages should be limited to the signed-in owner.
3. Test it as a stranger and as another user
Rules look right on paper more often than they work in practice. Log out and try to read each table through the API with only the public key, for example:
curl 'https://YOUR-PROJECT.supabase.co/rest/v1/YOUR_TABLE?select=*' \
-H "apikey: YOUR_PUBLIC_KEY"Then sign in as a second test user and try to open the first user’s records. Both tests should return nothing you shouldn’t see.
4. No secret keys in the browser
Lovable’s documentation says API keys and other secrets “cannot be stored safely in client-side code”, because anything in the frontend can be read by visitors. This matters even more for Supabase: a secret key (or the legacy service_role key) bypasses row-level security entirely. Keep these keys in Lovable’s Secrets and call them only from server-side functions.
5. Leaked-password protection is on
Lovable’s Quick scan flags this setting when it is off. Turn it on in your authentication settings so users can’t sign up with passwords already exposed in data breaches.
6. Dependencies have no known vulnerabilities
The dependency audit runs whenever your package files change. Read its findings instead of dismissing them, and update or replace packages with known security issues.
7. Your MCP server requires sign-in
If your app exposes an MCP server so AI assistants can use it, make sure it requires authentication. Lovable checks for unauthenticated MCP servers because an open one can give any AI client access to your app’s tools and data.
8. Run a Deep scan before launch
The Quick scan covers the database basics. The Deep scan reviews the whole codebase for problems such as injection, abusable endpoints, payment logic and exposed personal data. Run it before your first public launch and after major changes.
9. Get a human review if you handle sensitive data
If your app stores health data, payments, personal documents or anything a customer would be upset to see leaked, follow Lovable’s own advice and have a person review it before launch. Automated scans find common mistakes, but a reviewer can follow how your app is actually used.
Want us to check your Lovable app?
We offer a free security and SEO check for Lovable apps. Send us your app’s link and we’ll report what we find within 3 days. Your app stays on Lovable, and if something needs fixing we quote it at a fixed price before starting.
Sources: Lovable documentation: Security; Supabase documentation: Row Level Security; NVD: CVE-2025-48757. Checked 7 November 2026. Nowdigiverse is not affiliated with Lovable or Supabase.