Lovable is probably the tool I get asked about most, mostly because it's the one that quietly generates a full Supabase backend behind a simple chat interface, which is exactly the kind of magic that makes people nervous once they stop to think about it. Fair reaction. Here's what actually happens on the security side, as best I can tell from using it and watching what it flags.
Why this became a real feature, not just a nice-to-have
In March last year, an independent researcher named Matt Palmer found that a large number of Lovable-generated apps had Row Level Security missing or set up backwards on their Supabase tables, meaning anyone who found the right endpoint could read or write data that was supposed to be locked down. It went public at the end of May as CVE-2025-48757, and the numbers were not small: more than 170 live production apps confirmed affected, 303 vulnerable endpoints, across a sample of 1,645 scanned projects. A few weeks before that public disclosure, Lovable had already shipped a Security Scan feature as part of a version 2.0 release, aimed specifically at catching missing or misconfigured RLS before an app goes live.
What the scan actually looks for
From what I've seen using it, the publish-time check mainly looks at your Supabase tables and flags ones where Row Level Security is off, or where a policy exists but looks suspicious (overly permissive conditions, tables with no policy at all attached). It surfaces these in the publish dialog before your app goes live, which is the right moment for it, catching the exact class of problem that caused the CVE in the first place.
What it still leaves to you
- It checks whether a policy exists and looks reasonable. It doesn't fully verify that the policy does what you think it does against real user accounts, so a policy with subtly wrong logic can still pass.
- It's focused on the database layer. It doesn't check your custom API routes or edge functions for missing auth checks the same way.
- It doesn't check whether a key or secret ended up somewhere it shouldn't, like a front-end bundle.
- It won't catch business-logic problems: a discount code with no usage limit, a refund endpoint with no ownership check, that kind of thing lives outside what a database-focused scan can see.
What I'd actually recommend
Run the built-in scan every time, it's free and it catches the single most common Lovable mistake by design. Then go a level further yourself: open the Supabase dashboard directly, click into every table, and actually read the policy text rather than trusting a green checkmark. Log in as two separate test accounts and try to read each other's data through the app, not just through the dashboard. The scan is a real improvement, built specifically because of a real, publicly documented incident. It's also, by its own design, checking for one category of mistake. Everything outside that category is still on you to look for by hand.