Row Level Security mistakes in vibe-coded Supabase apps, and how to test for each.

Apps built with Lovable, Bolt and similar tools usually call Supabase straight from the browser with supabase-js. The key they use is meant to be public. Supabase’s own docs say of it: "Anyone can read it, so it only reaches what Row Level Security allows." Anyone can copy the key out of your JavaScript and send their own requests to your project’s REST endpoint. If a table has no RLS, or a policy that lets every row through, that request returns the table.

This has happened at scale. The record for CVE-2025-48757 says "an insufficient database Row-Level Security policy in Lovable through 2025-04-15 allows remote unauthenticated attackers to read or write to arbitrary database tables of generated sites." Lovable disputes it, on the grounds that each customer is responsible for protecting their app’s data. The researchers’ write-up lists what was reachable: user tables with names and emails, third-party API keys, payment and subscription records. In February 2026 The Register reported a showcased Lovable app exposing 18,697 user records; the researcher put it down to missing RLS and inverted access checks. Lovable said every project gets a free pre-publish security scan, that this one’s recommendations had not been applied, and that the vulnerable database was not hosted by Lovable.

Responsibility sits with whoever ships the app. The checks below take an afternoon.

Each one matches a check in Supabase’s Security Advisor (Database → Advisors), which names it with the lint shown.

In the Supabase SQL editor, run these three queries. The first lists tables with RLS off. The second prints every policy with its condition, so a true or a user_metadata stands out. The third shows what the anon role can touch at all. Supabase notes that RLS and grants both apply: a table needs a grant to be reachable, and RLS to limit which rows.

-- 1. Which tables have RLS on (false = readable by the public key)
select relname, relrowsecurity
from pg_class
where relnamespace = 'public'::regnamespace and relkind = 'r'
order by relrowsecurity, relname;

-- 2. Every policy, with its condition. Look for "true" and user_metadata.
select tablename, policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname in ('public', 'storage')
order by tablename;

-- 3. What the anon role is granted
select table_name, string_agg(privilege_type, ', ') as privileges
from information_schema.role_table_grants
where grantee = 'anon' and table_schema = 'public'
group by table_name;

Reading policies tells you what you meant. Calling the API tells you what happens. Use the same public key the app ships, from the outside, as an attacker would:

• Every table, logged out. Anything private should return []. A table with RLS on and no policy returns nothing, which is the safe default.
• Two accounts. Signed in as B, ask for A’s rows by id. Then try PATCH and DELETE on one of A’s rows. Run the write tests on a copy of the project, not on production data.
• Storage, logged out. In the browser console of the live app, call supabase.storage.from('<bucket>').list() for each bucket. A list of other people’s files is a leak.
• The bundle. Search the built JavaScript for service_role and for your secret key itself; the production checklist has the command.

URL=https://<project-ref>.supabase.co
KEY=<publishable or anon key, copied from the app's bundle>

# Logged out: should return [] or an error for anything private
curl "$URL/rest/v1/profiles?select=*&limit=5" -H "apikey: $KEY"

# Signed in as user B (access token from the browser's session):
# should return only B's rows, never A's
curl "$URL/rest/v1/orders?select=*&user_id=eq.<A's id>" \
  -H "apikey: $KEY" -H "Authorization: Bearer <B's access token>"

Wrapping auth.uid() in (select …) is Supabase’s own recommendation: Postgres evaluates it once per statement instead of once per row. Add to authenticated so the policy is never even considered for logged-out requests.

-- Turn RLS on. With no policy, nothing is returned to the public key.
alter table public.orders enable row level security;

-- Owners read and write their own rows
create policy "own orders" on public.orders
  for all to authenticated
  using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);

-- Admin checks read app_metadata, which users cannot edit
create policy "admins read all" on public.orders
  for select to authenticated
  using ((auth.jwt() -> 'app_metadata' ->> 'role') = 'admin');

-- Views run with the caller's rights (Postgres 15+)
alter view public.order_summary set (security_invoker = true);

Supabase Storage keeps its file records in storage.objects, and the same RLS rules apply. Uploads are blocked until you add an INSERT policy; upserts also need SELECT and UPDATE. A public bucket serves any file to anyone with its URL, so keep private files out of public buckets whatever the policies say.

-- Uploads only into a folder named after the user's id
create policy "own folder upload" on storage.objects
  for insert to authenticated
  with check (
    bucket_id = 'documents'
    and (storage.foldername(name))[1] = (select auth.uid()::text)
  );

RLS is a Postgres feature, not a Supabase one, and it works the same on any Postgres, including a Canner database. What Canner doesn’t have is Supabase’s REST API in front of the database, the anon and authenticated roles, or auth.uid(). A Canner database is reachable from inside Canner (your app, Data Workshop, scheduled queries) and, if you turn on external access, from the IP addresses you allow. There is no public key to copy.

So most apps on a normal backend enforce access in server code. The equivalent of a missing policy is a route that loads orders where id = $1 without and user_id = $2. Test it the same way: two accounts, swap the id.

RLS can still be a second layer behind those checks. Set the user for each transaction and write policies against it:

alter table notes enable row level security;
alter table notes force row level security;   -- the table owner too

create policy notes_owner on notes
  using (user_id = nullif(current_setting('app.user_id', true), '')::uuid);

• `set_config(…, true)` lasts for the transaction only, so the user can’t leak into the next request on a pooled connection.
• `nullif(…, '')`: with no user set, the policy compares against NULL and returns no rows. On a reused connection the setting can come back as an empty string, which would fail the uuid cast; nullif turns it into NULL.
• The table owner skips RLS unless the table has FORCE ROW LEVEL SECURITY, and superusers and BYPASSRLS roles always skip it. If your app connects with the login that ran the migrations, it owns the tables. Either force RLS or give the app a role that doesn’t own them; on the dedicated instance, canner db least-privilege does that in one step.
• Forced RLS and Canner backups: a backup taken as the owner stops with a row-level-security error on a forced table. Set Backups run as to the instance superuser on the dedicated instance (docs).

// node-postgres: set the user for this transaction only
await client.query("BEGIN");
await client.query("SELECT set_config('app.user_id', $1, true)", [session.userId]);
const { rows } = await client.query("SELECT * FROM notes WHERE id = $1", [id]);
await client.query("COMMIT");