The Lovable Migration Security Checklist
A security checklist for migrating off Lovable. Row-level security, exposed keys, auth providers, edge functions and storage, informed by CVE-2025-48757.
A migration is the one moment you look at every table, key and policy in your app. That makes it the best time to fix security, before you move the problems somewhere new.
What CVE-2025-48757 showed
In 2025, security researcher Matt Palmer scanned 1,645 apps built with Lovable and found 170 (about 10.3%) with database tables that unauthenticated users could read or write, across 303 vulnerable endpoints. The cause was missing or incomplete row-level security (RLS). The CVE was rated high severity.
The lesson isn’t unique to Lovable. Any app where the browser talks directly to the database depends entirely on its RLS policies. If a policy is missing, the public key in your frontend is enough to read the table.
Lovable improved its defaults after the disclosure. Apps built earlier, or policies changed by later prompts, still need checking.
Row-level security
- RLS is enabled on every table in the public schema
- Each table has explicit policies for select, insert, update and delete
- Policies use
auth.uid()to limit rows to their owner, where that’s the intent - Admin-only tables can’t be read with the publishable key
- Tested as an anonymous user: queries on private tables return nothing
- Tested as a normal user: you can’t read or change another user’s rows
Keys and secrets
- No secret keys (service role, Stripe secret, AI keys) in frontend code or the repo
- Only the publishable (anon) key is in the frontend
- Every secret re-issued during the migration, not copied
- Old keys revoked after cutover
- AI calls go through edge functions or your API, never from the browser
Auth
- Email confirmation settings match your intent
- OAuth apps (Google, GitHub, Apple) re-created on your own accounts
- Redirect URLs list only your real domains
- Password reset and magic-link emails come from your domain
Edge functions
- Each function checks the caller’s identity when it should
- Inputs are validated
- CORS allows only your domains
- Functions using the service role key can’t be abused to bypass RLS
Storage
- Private buckets are private
- Storage policies limit access to the file’s owner
- Public files contain nothing sensitive
After cutover
- Automated backups turned on and one restore tested
- Logs and alerts for auth failures and unusual traffic
- A re-check of RLS whenever a new table is added
X & Company runs this checklist on every Lovable migration. If you’d like a second pair of eyes, start with a free assessment.