Home GuidesHow to check Supabase RLS on a Lovable app

Guide

How to check Supabase RLS on a Lovable app

Check RLS on a Lovable app step by step: find your backend, read the Policies view, run two read only SQL queries, test as a stranger, then scan for free.

Published November 2, 202612 min read

Independent notes from VibeLocked. Not a pentest, and not affiliated with the tools named below.

To check Supabase RLS on a Lovable app, first find out which backend it uses. On Lovable's built-in backend (Lovable Cloud), you read your rules in More, then Database, then Manage, then Policies and run the scans in More, then Security. On your own connected Supabase project, you use the Supabase dashboard and its Security Advisor. Then, on either backend, run two read only SQL queries and test the live app as a stranger and as a second user. Each step catches something the others miss.

Checked on November 2, 2026 against Lovable's documentation, Supabase's documentation, the PostgreSQL docs and the CVE-2025-48757 record, all linked in the sources. The two SQL queries were run on a test PostgreSQL 17 database with a table that had RLS off and one that had a using (true) policy. The Lovable menu paths come from Lovable's docs; we did not click through a Lovable project for this guide. VibeLocked is independent and not affiliated with Lovable or Supabase.

The short version

Find your backend first. The places you check are different.
Run Lovable's Quick and Deep security scans. They are free. Treat a clean result as a start, not a pass.
Read every policy. Watch for rules that apply to anon (signed out visitors) and rules that are just true.
The Policies view lists policies, not tables. A table with RLS off can have no policies at all, or policies that do nothing. Use the SQL query below to find those.
Test from the live app as a signed out visitor and as a second account.
Run a free LeakCheck scan to see what a stranger can read with your public key.

Why RLS decides whether a Lovable app leaks

Lovable apps usually talk to the database straight from the browser, using a public key. The researcher behind CVE-2025-48757 put it this way: Lovable builds frontends that make direct REST calls to the database with the public anon key, "while relying exclusively on RLS to ensure the privacy and integrity of the contents of the database" (Matt Palmer).

Supabase's own warning is short: "A table in an exposed schema without RLS is readable and writable by any role with a grant on it" (Supabase RLS docs). So the public key is fine to ship. What matters is what RLS lets it do. If you are unsure about keys, read Supabase anon key vs service role key.

Lovable's docs agree that the rules matter. They say Lovable "sets up basic RLS policies automatically", that you "should review and adjust them early in development", and that server code using the service role bypasses RLS and "must check permissions itself" (Lovable security best practices).

Step 1: Find out which backend your app uses

Lovable apps store data in one of two places (Lovable built-in backend, Connect to Supabase):

	Built-in backend (Lovable Cloud)	Your own Supabase project
Where you manage data	Database, Users and Storage views inside Lovable	The Supabase dashboard
Where you read policies	More, then Database, then Manage, then Policies	Supabase dashboard (and its Security Advisor)
How you change a policy	Ask Lovable in the project chat (the Policies view is read only)	Ask Lovable, or edit in Supabase
SQL editor	More, then Database, then Manage, then SQL editor	Supabase dashboard SQL Editor

How to tell: Lovable's docs say that after you connect your own Supabase project, More, then Supabase shows that project's name and status with links to the Supabase dashboard. If you never connected one, you are most likely on the built-in backend. Lovable says the built-in backend is built on Supabase's open-source foundation, so RLS works the same way on both.

Step 2: Run the Quick scan and the Deep scan

Open More, then Security. Lovable has two built-in scans (Lovable security overview):

Quick security scan runs automatically every time you publish. Its database review covers tables without RLS, "access rules that let everyone through", and leaked password protection being off.
Deep security scan reads all of your app's code. It also looks for "server code that bypasses the rules your database enforces". It does not run on its own, so start it yourself. Lovable says it usually takes 3 to 13 minutes (Project security view).

Both scans are free. Asking Lovable in chat to "review my app's security" uses credits, though the scans it starts are free.

Fix every Critical finding. Then keep going. Lovable's own wording: when it shows No issues found, "the scanner cannot catch every possible risk". The scans read your code and settings. They do not sign in as two users and try to read each other's data.

Step 3: Read every policy

On the built-in backend

Go to More, then Database, select Manage, then Policies (Lovable database access). Each row shows the policy name, the Command (SELECT reads, INSERT adds, UPDATE changes, DELETE removes), Applies to (for example authenticated or anon) and the Rule expression. Expand a row to read the rule. Use the Tables, Storage and Realtime filters so you also see file and live update rules.

Read them with these questions:

Does anything private apply to anon? anon means a signed out visitor. A SELECT policy for anon on a table of orders, messages or profiles is a leak.
Is the rule just true? Supabase warns that to anon using ( true ) "grants every unauthenticated visitor read access to every row the role can already reach through grants". On a signed in table, true means every user sees every other user's rows. See using (true) and permissive policies.
Does the rule tie rows to the user? Private data should compare a column like user_id with auth.uid(). Team data should check membership.
Can a user change their own plan, role or credits? An UPDATE rule that only checks ownership lets people edit every column in their row. See column level security for role, plan and credits.
Is every table in your Database view covered? The Policies view filters by table. A table that holds user data and has no policy listed needs a closer look in Step 4.

You cannot edit policies in this view. To change one, ask Lovable in the project chat. Lovable's docs give "Only allow users to see their own invoices." as an example.

On your own Supabase project

Open the Supabase dashboard and run the Security Advisor. The checks that matter here are 0013 rls disabled in public, 0007 policy exists rls disabled, 0008 rls enabled no policy and 0024 permissive rls policy (Supabase Database Advisors). For what each warning means and which are urgent, see Security Advisor warnings and fixes. Then read your policies with the same questions as above.

Step 4: Run two read only SQL queries

The Policies view shows rules. It does not show whether RLS is actually on. That gap matters both ways:

A table with RLS off is open to any role with a grant, and it may have no policies listed at all.
A table can have policies listed while RLS is off. Those policies do nothing. Supabase's Advisor calls this "policy exists rls disabled".

Both queries below only read the database catalog. They change nothing. On the built-in backend, open the SQL editor from More, then Database, then Manage. On your own Supabase project, use the dashboard SQL Editor.

Tables with RLS off:

select tablename
from pg_tables
where schemaname = 'public' and rowsecurity = false;

rowsecurity is true when row security is on for that table (PostgreSQL pg_tables). Every table this returns needs RLS turned on, unless you are sure it is not reachable from the app.

Policies whose rule is just true:

select tablename, policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname = 'public'
  and (qual = 'true' or with_check = 'true');

qual is the USING rule and with_check is the WITH CHECK rule (PostgreSQL pg_policies). In our test, a policy created with no to clause showed up with roles {public}, which means it applies to every role, including signed out visitors. Each row here is fine only if the table really holds public data.

If an editor refuses either query, ask Lovable in chat to list tables with RLS off and policies whose rule is true, and to show you the result without changing anything.

One more Supabase point: policies do not remove grants. Supabase says "Adding policies doesn't remove them", and that on existing projects new tables in public start with every privilege granted to anon and authenticated (Supabase RLS docs, Securing your API). See 42501 permission denied and grants before you revoke anything.

Step 5: Test the live app as a stranger and as a second user

Scans and SQL show your rules. This step shows what people can actually reach. Lovable's own pre-publish list includes "Users cannot access other users' private data" (Lovable security best practices). You can test that from the app itself, with no code:

Sign up two test accounts, A and B. Use addresses you control.
As A, create something private, like a note, an order or a profile detail.
Open the live app in a private window, signed out. Visit pages that should need sign in. Nothing private should load.
Sign in as B. Open A's item by changing the id in the address bar, if your app puts ids there. It should show nothing.
As B, try to edit or delete anything that belongs to A.

If B can see or change A's data, the rule for that table is too broad. See IDOR in Next.js and Supabase for the pattern and the fix. Do not run tests from an editor inside Lovable or the Supabase dashboard and call it done. Those are owner tools, not what a stranger sees.

Step 6: Scan the live app from outside

LeakCheck looks at your live app the way a stranger would. Here is what it does with Supabase, from its code:

It looks in your page and JavaScript for a Supabase project URL ending in .supabase.co together with a public anon or publishable key. The public key on its own is reported as a note, not a leak, and does not lower your grade.
With that public key, it tries to read one row from up to 35 tables, using table names found in your JavaScript, the REST schema if it is readable, and common names. Each table that returns rows is listed as its own finding with the table name.
It flags when the REST schema lists your tables or functions to the public key, and when sign up is open with email confirmation off, which turns any authenticated rule into an "anyone with an email" rule.
It checks Supabase Storage buckets it finds, read only.

It uses read only requests. It never creates users or writes data. That also sets its limits: it does not test INSERT, UPDATE or DELETE rules, and it does not sign in as two users. If your app's JavaScript does not contain a .supabase.co URL and a public key, the table checks do not run. That is why Steps 2 to 5 still matter.

The first scan needs no account. For other ways to check, see free Supabase RLS checker: 3 ways.

Fixing what you find

On the built-in backend, ask Lovable in the project chat to change the policy, then read the new rule in the Policies view. Lovable's example prompt: "Review RLS policies to ensure users can only access their own data and shared data is properly protected."
Lovable can auto-fix some Critical database findings from the Quick scan when you send a build request, if auto-fix is on for the project (Lovable security overview). Read what changed. An AI fix that gets an error out of the way by allowing everything is not a fix. If you hit an infinite recursion error on team or admin rules, see the fix that keeps RLS on.
If a table was open with real user data in it, treat it as possible exposure. Check who could have read it, and rotate anything sensitive stored in it, like third party tokens.
After any fix, rerun the Quick scan, rerun the two queries and rerun the stranger test.

Where sources disagree

CVE-2025-48757. Palmer's write-up rates it 8.26 (CVSS 3.1) and says it affects Lovable projects using a database created on or before April 15, 2025, and possibly later ones. NVD's record says Lovable disputes it "because each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application" and lists it as Deferred (NVD, GitHub Advisory). Both sides end up in the same place for you: the rules are yours to check.
What Lovable's scan is. An earlier Lovable blog post says Lovable integrated Supabase's Security Advisor into its pre-publish scan (Lovable blog). Its current docs describe a Quick scan with its own database review and a Deep scan that reads code. Go by the current docs, and expect the details to keep changing.
Default grants. Supabase's docs say existing projects grant every privilege on new public tables to anon and authenticated, that not every project does, and that Supabase is changing the platform default so exposure becomes opt in. Check your own project rather than assuming either way.
Who policies cover. Lovable's database access page describes a policy as deciding which rows "a signed-in user" can see, but the same page lists anon under Applies to. Policies can cover signed out visitors too, which is exactly what to look for.

Checklist

Prompt for Lovable

Paste this into the Lovable project chat. It asks for names and rules only, never keys or passwords.

Review the row level security on every table, storage bucket and realtime channel in this project. List: tables with RLS turned off, policies that apply to anon, policies whose rule is just true, and UPDATE policies that let users change columns like role, plan or credits. Do not change anything yet. For each problem, explain the risk in one sentence and show the policy you would use instead, so each user only reads and changes their own rows.

Review the answer before you let it change anything, then run the checks above again.

Sources

Check yours now

See which tables a stranger can read in your Lovable app. Run a free LeakCheck scan. When you ship often, LeakCheck Pro rescans after every deploy.

Questions

Does Lovable turn on RLS automatically?

Lovable's docs say it sets up basic RLS policies automatically when it builds features that store user data, and that you should review and adjust them early. Automatic is not the same as correct, so read each policy before you publish.

Where do I see RLS policies in Lovable?

On the built-in backend, go to More, then Database, select Manage, then Policies. The view is read only and lists each policy's name, command, who it applies to and its rule. If your app uses your own Supabase project, use the Supabase dashboard instead.

Is a clean Lovable security scan enough?

No. Lovable says its scans cannot guarantee complete security and that No issues found means the last scan did not surface anything, not that nothing is wrong. Test as a second user and scan the live app from outside too.

Is the Supabase anon or publishable key in my Lovable app a leak?

No. It is meant to be in the browser. It is only safe when every exposed table has RLS on with policies that limit each user to the rows they should see.

What was CVE-2025-48757?

A CVE published in May 2025 by Matt Palmer saying Lovable projects shipped with missing or weak RLS, letting strangers read or write tables. NVD lists it as disputed by Lovable, which says each customer is responsible for protecting their app's data. Either way, checking RLS is your job.