Is my Lovable app secure? The Supabase RLS gap and how to close it

What is the main security risk in a Lovable app?

The main risk in a Lovable app is missing Row Level Security (RLS) on your Supabase tables. When Lovable creates a table, it runs the CREATE TABLE statement but often does not enable RLS or write any access policy. Without those rules, the public anon key embedded in your app can query the database directly and return every row in the table.

This isn't a hypothetical. In 2025 a security researcher scanned 1,645 public Lovable projects and found 170 with inadequate row-level security, exposing 303 endpoints that leaked names, emails, phone numbers, home addresses, payment information, and third-party API keys. The issue was catalogued as CVE-2025-48757, and Lovable has since updated its code generation to include RLS policies in new schemas. The takeaway isn't "Lovable is unsafe", it's "Lovable-generated apps need RLS turned on and checked before real users arrive."

Why does Lovable produce the missing-RLS pattern?

Lovable produces this pattern because it, like most AI app builders, generates a schema that works before it generates one that is locked down. Getting a table created and a form saving data is the visible win; RLS policies are invisible plumbing the AI often skips. Lovable can add RLS, and after CVE-2025-48757 it updated its generation pipeline to do so by default, but older projects and hand-edited schemas can still be exposed, and a non-technical founder has no easy way to tell whether their tables are protected.

That's the real gap: not that RLS is hard to turn on, but that you can't see whether it's on. Explain My Build reads your migrations and Supabase config and tells you, table by table, which ones have policies and which are wide open, cited to the file.

What does an exposed Lovable table look like in code?

An exposed table looks like a normal, working table, that's what makes it easy to miss. Here's the shape Explain My Build points at, cited to your migration:

create table orders (
  id uuid primary key,
  user_id uuid,
  email text,
  amount_cents integer
);
-- Missing: alter table orders enable row level security;
-- Missing: a policy restricting rows to the owner.
-- Result: the anon key can read every order, including emails.

Because your front end already ships the Supabase URL and anon key (it has to, to work), anyone can point a request at your database and pull that whole table. The fix is to enable RLS and add a per-user policy so a request only ever returns the current user's rows.

The fix-list prompt Explain My Build generates reads like: "Enable Row Level Security on the orders table. Add a policy so authenticated users can select only rows where user_id = auth.uid(). Give me the SQL migration and confirm no policy allows anon reads."

Are there other Lovable flaws besides RLS?

Yes. Alongside RLS, Lovable apps commonly show two related issues. First, keys and secrets landing in the client: anything the browser can see, an attacker can see, so a service_role key or third-party API key in the front-end bundle is exposed. Second, client-side-only access control: hiding a page or button in JavaScript feels secure but is trivially bypassed by calling the database or an API directly.

Both trace back to the same root cause as RLS, the security boundary needs to live in the database or on the server, not in the browser. Explain My Build reads your source and flags each spot where a secret is exposed or a check exists only client-side, with the file cited. Our API key and environment variable entries explain where secrets should live.

What you get for your Lovable app

Paste your repo (or run it locally so code never leaves your machine) and Explain My Build gives you, each cited to your code:

• A plain-English breakdown of every table missing RLS and every exposed secret, written for a founder, not an engineer.
• A ranked, code-verified fix-list to hand your AI so the change actually gets made.
• A founder runbook that maps how your Lovable app is wired.

The runbook and fix-list are free. The shareable end-user guide is $19/month (or $12/month founding for the first 100), see pricing. When you're ready, start by documenting your Lovable app so you know every table that needs a policy.