Security scanning for Lovable apps

What a Lovable app is made of

• A Vite/React single-page app
• Supabase for the database and auth
• Deployed to a lovable.app subdomain or your own

The row-level security gap

Your Supabase publishable key ships in the browser by design. It is not a secret, and it is not the problem. What protects your data is Row Level Security — a rule on each table saying who may read which rows.

The failure is that a new table arrives with that rule OFF. Add a feature, get a table, and unless a policy is written for it, anyone who opens your site can read everything in it. CVE-2025-48757 documented this at scale: a scan of 1,645 apps from Lovable's own public showcase found around 10% exposing real data — names, emails, phone numbers, addresses, payment details.

We check it the only way that actually proves anything: by sending the same request your own front end sends, with your own public key, and seeing whether rows come back. We record the column names and the row count. We never record a single cell of the data.

The checks that matter here

• Database readable by anyone (Supabase RLS)The one that matters most on this platform, and the one no mature scanner runs.
• Exposed secret / misconfigurationWe read the bundle AND its code-split chunks and source maps. A server key pasted into a VITE_ variable ends up in a file anyone can download.
• Publicly served config fileConfirmed by content, not by status code — a single-page app answers 200 for every path, so a naive check reports an exposed .env on every SPA in existence.
• LLM prompt injection and data disclosureIf you wired an assistant in, it is part of your attack surface.

What this does not cover

• The free instant check does not test anything that requires sending an attack payload. Those need proof you control the site.
• An unauthenticated scan does not cover your signed-in surface. A policy that lets ANY logged-in user read everyone's rows needs a session to detect, and we say so rather than implying otherwise.