Security scan for Lovable apps: what to check before you launch

The 5 most common issues in Lovable apps

1. RLS disabled or too open. If a table has RLS off, or a policy like using (true), anyone with your public anon key can read or change every row. The anon key is in your frontend by design, so RLS is the only thing protecting your data. See Supabase RLS misconfiguration.
2. "Signed in" treated as "allowed". A policy like auth.role() = 'authenticated' lets every signed-in user see every other user's rows. Signing up is free, so this is almost as open as no policy. Check ownership instead: auth.uid() = user_id. See IDOR.
3. Secret keys in the browser. Anything in a VITE_ variable is bundled into the JavaScript every visitor downloads. The Supabase service_role key, a Stripe secret key or an OpenAI key must never be in one. See Supabase service_role key exposed in the browser and Exposed secrets & API keys.
4. Edge Functions that trust the client. If a function takes the price, plan, credits or user ID from the request body, anyone can change it in DevTools. Read those from the database or the verified session instead. See Client-trusted prices.
5. Public storage buckets. A public bucket for avatars is fine. A public bucket for invoices, uploads or IDs is not.

How to check your Lovable app yourself

1. In Supabase, open Table Editor and look for tables marked RLS disabled. Open Authentication → Policies and read each policy for true or a check that only tests whether the user is signed in.
2. Search your code for VITE_ and read every variable name. Only the Supabase URL and the anon or publishable key belong there.
3. Open each Edge Function and look at what it reads from the request body. Anything about money, plans, roles or other users should come from the server side.
4. In Storage, check which buckets are public and what's in them.

How to scan it with SetRepo

1. In Lovable, connect your project to GitHub so the code is in a repo you own.
2. On SetRepo, connect that repo (read-only access) or upload a zip, and add your live URL if the app is published.
3. Run a free Quick scan. From the code it checks keys in your files and git history, Supabase migrations that leave RLS off, true policies and public buckets, the service_role key behind a VITE_ prefix, Edge Functions and other routes that change data without a sign-in check, and known-vulnerable packages. With your live URL it also checks HTTPS, security headers and the JavaScript the site serves for keys and exposed Supabase config.
4. The free report shows every finding's title and severity, with full details for the top few. A Deep scan unlocks every finding with a fix prompt you can paste into Lovable's chat.
5. A Deep scan also adds an AI review of access control and business logic: whether one user can reach another user's data, or an Edge Function trusts a price or plan sent from the browser.

FAQ

Is my Supabase anon key in the browser a problem?

No, it's meant to be public, as long as RLS is on for every table and the policies check who owns each row.

Does SetRepo change my Lovable project?

No. GitHub access is read-only, and your code is deleted when the scan finishes.

I deleted a key from my code. Is it still exposed?

It can be. A key that was committed stays in your git history, and anyone who can read the repo can find it there. When you connect a repo, SetRepo checks the last 100 commits of the default branch for keys, not just the current files. A zip upload has no history, so only its files are checked. If a key was ever committed, rotate it.

What does it cost?

The Quick scan is free with no credit card. A Deep scan is a one-time payment, and there are monthly plans if you scan often. See pricing.