Is my Lovable app secure?

Lovable publishes a front end. The HTML, the same-origin scripts, and a handful of well-known files are what any visitor can download. That is the whole of a ShipShape Quick Check: leaked keys, exposed files such as /.env, missing security headers, cookie flags, and whether the URL stays on HTTPS. Matched secrets are masked. The free page writes out the fix for the single most serious finding.

The €19 Launch Report opens the rest of that same pass. It does not crawl further and it does not log in. Monitor, €9 per month, runs that same passive check every week and when a deploy hook fires. It is how you notice a later publish that adds a key or drops a header. It is not a second kind of test.

Lovable’s own docs describe two backends. The built-in Cloud backend is on by default and is managed inside Lovable. You can instead connect a Supabase project you own, and Lovable then creates tables, auth flows, storage, and edge functions in that project. Supabase’s troubleshooting note says the same split: Lovable Cloud does not appear in your Supabase dashboard and does not hand you the service role key; a connected project does. Sources: Connect to Supabase and Identifying Lovable backend.

An anon key in the browser bundle is normal for both. A service_role key in that bundle is not. Lovable’s integration page says API keys for services such as Stripe should stay in the Supabase project, not in the app code. If a scan shows one in the page, rotate it. The scan cannot tell you whether row level security is on.

Ask whether each table the client reads has row level security enabled and a policy that matches the role. From 30 October 2026, a new table in public on an existing Supabase project also needs an explicit GRANT or supabase-js fails with 42501. Disabling RLS is not the fix. The 30 October explainer and the RLS check walk through both.

Lovable’s auth docs say a connected Supabase project does not get automatic Site URL and redirect URL updates. If sign-in works in the Lovable preview and fails on the published domain, those URLs are the usual cause. That is configuration, not something a fetch of the homepage can see. Source: Users and authentication.

Run the free check on the published URL, not the editor preview. Rotate anything it shows in the page.

In the Supabase or Lovable Cloud database view, confirm RLS is enabled on tables the client can name.

For a new public table after 30 October 2026, add the GRANT and the policy in the same migration.

If you keep shipping, turn on Monitor so the next publish is checked the same way without starting over.