Is your Lovable app secure?

Lovable generates a React front end (Vite, TypeScript, Tailwind) and connects it to a Supabase backend, either your own Supabase project or Lovable Cloud, which is built on Supabase. It publishes the site for you on a lovable.app address or your own domain, with HTTPS.

That covers the servers, the certificates and the database engine. It does not decide who is allowed to read which rows in your database. That is set by row level security (RLS) policies in Supabase, and they are part of your app, not the platform.

The reason this matters: a Lovable app talks to Supabase straight from the browser. The Supabase URL and the anon (or publishable) key are in your JavaScript, and that is by design. Anyone can copy them and send their own queries. RLS is the only thing deciding what those queries return.

• A table with RLS turned off. Anyone holding the public anon key can read, edit or delete every row in it.
• RLS turned on with a policy like using (true). The switch is on, but the policy lets everyone in, so it behaves the same as off.
• A table that is locked down, plus a view or a database function over the same data that is not. Views run with their owner's permissions by default, which skips RLS.
• The service_role key or an sb_secret_ key pasted into front end code to get past a permissions error. That key ignores RLS entirely.
• An OpenAI, Stripe or other paid API key called from a React component instead of a Supabase Edge Function.
• A storage bucket set to public that holds user uploads such as ID photos or invoices.

Lovable has built in security scans: a quick scan that runs when you publish and checks your database access rules, and a deeper scan of your code you can run yourself. Fix what they flag, but treat a clean result as a starting point. A policy can be switched on and still say the wrong thing.

• RLS and policies: in Supabase, either in the SQL editor or as a migration you ask Lovable to write. Check the result in the database itself, not only in the chat.
• Secret API keys: in Lovable's Secrets manager if you use Lovable Cloud, or in Supabase Edge Function secrets if you connected your own Supabase project. Either way they are used only inside an Edge Function. The browser calls the function, and the function calls the paid API.
• Storage: bucket settings and storage policies, next to your database settings.
• Security headers: Lovable's hosting gives you limited control over response headers. A Content-Security-Policy can go in a meta tag in index.html, but a meta tag cannot set frame-ancestors or HSTS. For full control, sync the project to GitHub and deploy it on a host where you set headers, such as Netlify or Vercel.

Go through every table in the public schema of my Supabase project. Make sure row level security is enabled on each one, and write policies so users can only read and change their own rows (matching auth.uid() to the owner column). Remove any policy that uses true. Move any secret API key out of the React code into an Edge Function that reads it from the project's secrets. Show me the SQL before you apply it.

1. If you connected your own Supabase project, open Advisors, Security Advisor and fix every error about RLS being disabled on a public table. On Lovable Cloud, run Lovable's security scan instead.
2. Read each policy in Authentication, Policies. If a policy on user data says true, rewrite it to compare auth.uid() to the owner column.
3. Search the project for service_role, sb_secret_ and sk_ keys. None of them should appear in src/.
4. Check that each paid API is called from an Edge Function, not from the browser.
5. Set storage buckets that hold private files to private.
6. In Supabase Auth settings, limit redirect URLs to your real domains.
7. Run an outside scan of the published URL.

The quickest RLS test is to act like a stranger. Take the anon key from your own site's JavaScript and ask Supabase for a table that should be private. If you get rows back without logging in, that table is open.

curl 'https://YOUR-PROJECT.supabase.co/rest/v1/profiles?select=*&limit=5' \
  -H 'apikey: YOUR_ANON_KEY'

An empty list [] means RLS blocked the read. A permission error means the anon role has no access to the table at all. Rows mean anyone can read them.

Our scan covers the outside of the app. It loads the page and your own JavaScript bundles and looks for leaked secret keys, including Supabase service_role JWTs and sb_secret_ keys (it treats the anon key as public, which it is). It also checks for public .env and .git files, security headers, cookie flags and CORS. It cannot read your database, so it cannot tell you whether RLS is on. Use the Security Advisor and the curl test above for that.