Is Lovable secure? What to check before your users do

Lovable hosts your app and Supabase hosts your database. Both run on infrastructure that is maintained and patched. What they cannot decide for you is who is allowed to read which rows, which keys go where, and which headers your app sends. Those are app decisions, and they are where the holes are.

An independent researcher who scanned 62 Lovable apps found critical or high-severity findings in 63% of them, and 77% of those apps ran on Supabase. A separate study by RedAccess, reported by WIRED, found more than 5,000 apps on Lovable, Replit, Base44 and Netlify lacking basic security, with about 40% of them leaking private data.

• Row-level security is on for every table in the public schema.
• No policy uses using (true) on a table that holds personal data.
• The only Supabase key in your frontend is the anon or publishable key, never the service role or secret key.
• Storage buckets with customer files are private.

Open your Supabase project, go to the Table Editor and look for tables marked as unrestricted. Or run this in the SQL editor to list every public table with row-level security off:

select tablename
from pg_tables
where schemaname = 'public'
  and rowsecurity = false;

Lovable's built-in security check is worth running on every publish. It sees your project from the inside. An outside scan adds what the inside view misses: what your public key can actually read, what your old commits still contain, and what headers your live site sends.