Security review for Lovable and Supabase apps

Where Lovable apps actually leak

• Row-level security missing or written as "true" — any signed-in user (or anyone with the public anon key, which is in your JavaScript by design) can read other tenants' rows.
• A service-role key shipped to the browser, usually via an edge-function call copied into the front end.
• Secrets committed to GitHub: .env files, Stripe keys, webhook signing secrets.
• Webhooks that do not verify signatures, so anyone can "mark an order paid".
• Authorization done in the UI only — the button is hidden, the API call still works.
• Storage buckets that are public when they should not be, and file paths that are guessable.
• Prompt-injection paths where user text is fed to an LLM that can then call privileged functions.

What the review covers

• Every table: RLS enabled, policies read line by line, tested with two real accounts trying to reach each other's data.
• Every edge function: authentication, input validation, secret handling, error responses.
• The bundle and the repo: keys, .env history, source maps, exposed endpoints.
• Auth flows: sign-up, password reset, OAuth, session handling, email deliverability (SPF/DKIM).
• Payments and webhooks: signature verification, idempotency, out-of-order events.
• A written report in plain English with severity, proof, and the fix for each item — the document you hand to a customer's IT team or an acquirer.

Fixing it, not just finding it

A scanner tells you the door is open. I close it: rewriting policies, moving privileged logic server-side, rotating exposed keys, adding signature checks, and then re-testing with the same two-account method. If your app is on Lovable Cloud and the fix needs database access you do not have, the review usually pairs with a migration to your own Supabase project.

Questions