Lovable security checklist

The checklist

• Row Level Security is enabled on every Supabase table in the public schema.
• Every table with RLS has policies that limit rows to the right user, not "using (true)" for everyone.
• Only the Supabase anon (publishable) key appears in your frontend. The service_role key never does.
• No other secret-shaped strings (OpenAI, Stripe secret, Resend, etc.) appear in your JavaScript bundles.
• Paths like /.env, /.git/HEAD and backup files return 404, not content.
• Your site is served over HTTPS and redirects plain HTTP.
• Basic security headers are set (Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, frame protection).
• Email confirmation and rate limits are on for sign-up, so bots cannot mass-create accounts.
• Storage buckets that hold user files are private unless they truly need to be public.
• Edge functions that call paid APIs check who is calling before they spend money.

Why RLS matters most

Your Supabase anon key is public by design: it ships to every visitor's browser. That is fine only when Row Level Security decides what each request may read or write. If RLS is off for a table, anyone with your anon key can query that table directly, without using your app's UI at all.

-- Turn on Row Level Security for a table
alter table public.profiles enable row level security;

-- Let signed-in users read and update only their own row
create policy "Own profile read" on public.profiles
  for select using (auth.uid() = id);
create policy "Own profile update" on public.profiles
  for update using (auth.uid() = id);

A fix prompt you can paste into Lovable

Review every Supabase table this app uses. Enable Row Level Security on each one, and add policies so users can only read and change their own rows (match on auth.uid()). List any table that must stay public and explain why. Do not use the service_role key anywhere in frontend code.