Supabase · Row level security · Two-account proof
Supabase RLS audit: find and fix leaking row level security policies
A Supabase RLS audit checks that every table holding user data has row level security enabled and a policy that limits each user to their own rows, then proves it by trying to break in from a second account. It matters because AI coding tools build working apps quickly but are less careful about who can read which rows. In 2025, researchers checked 1,645 Lovable-built apps and found 170 that let anyone read personal data because RLS was missing (CVE-2025-48757; Lovable disputes the record and says each app owner is responsible for their own data).
The three RLS mistakes we see in AI-built apps
- RLS is off. Any signed-in user, or anyone holding your public anon key, can read every row.
- A policy says
using (true). RLS is on, but the policy allows everything, so it protects nothing. - Policies cover SELECT but not UPDATE or DELETE. Users cannot read each other's rows but can still change or delete them.
Check it yourself first
These two queries in the Supabase SQL editor show the obvious gaps:
-- tables in public with RLS switched off
select tablename from pg_tables
where schemaname = 'public' and rowsecurity = false;
-- policies that allow everything
select tablename, policyname, cmd, qual
from pg_policies
where schemaname = 'public' and (qual = 'true' or with_check = 'true');A scanner or Supabase's Security Advisor can flag these. What a scan cannot do is show that a fix works on your real app. That needs a test with two real accounts.
How we prove isolation
We create two test users. User B then tries to read, insert, update and delete user A's rows through the same API your app uses. Every attempt must fail, and the results table goes in your report. You see pass or fail for each table and each operation, not a list of “possible issues”.
What you get
A Launch Pass ($499, founding price $399 for the first five customers) fixes grants and RLS, with one pull request on your repo, two-account proof, Stripe webhook and auth checks, and a plain-language proof report in 48 hours. We work on a staging copy under a signed testing authorization, so we never need your production database password.
Questions
What is a Supabase RLS audit?
A review of every table that holds user data to confirm row level security is enabled and the policies limit each user to their own rows, followed by a test from a second account that shows the policies hold.
Does Lovable's built-in security scan replace an audit?
It is a good first step and worth running. A scan lists possible problems; it does not fix them or prove the fixes on your app. A pass fixes the policies in a pull request and tests them from two accounts.
Do you need my production database password?
No. We work on a staging copy with test accounts under a signed testing authorization. You review and merge the pull request yourself.
Request Launch Pass See pricing