Lovable
Security scan for Lovable apps
Lovable generates both your frontend and your Supabase schema, which is what makes it fast and also what makes the access-control gap easy to miss. The generator will happily create tables and wire up queries without ever configuring who is allowed to read which rows.
That gap became a documented one: CVE-2025-48757 covers Row Level Security misconfiguration in Lovable-built apps, where a survey of published projects found a meaningful share allowing unauthenticated reads of arbitrary tables. If you have not explicitly written RLS policies, assume you do not have them.
Scan your app
Or run it yourself
$pip install overshare$overshare https://myapp.lovable.app --fail-on high
What usually turns up on Lovable apps
01
Supabase keys in the client bundle
The anon key is meant to be public. The service_role key is not — it bypasses Row Level Security completely, and if it reached your frontend it is readable by anyone who opens developer tools.
02
Row Level Security never configured
Enabling RLS with no policy denies everything; adding a policy of USING (true) protects nothing. Both look equally 'done' from the dashboard.
03
Source maps left on
Default build settings often publish .map files, which reconstruct your original source alongside the minified bundle.
What the scan actually does
It fetches your app the way any visitor's browser would, reads the JavaScript it ships, and checks the headers, certificate and DNS records that go with it. No login is attempted, nothing is modified, and no credential is used that was not already public.
See the full check list →