How to fix Lovable RLS (Supabase Row Level Security), step by step

To fix broken RLS on a Lovable app: open your Supabase dashboard, enable Row Level Security on every table that holds real data, then write an explicit policy for each operation (select, insert, update, delete) that checks auth.uid(). Then — and this is the step everyone skips — verify it actually blocks an anonymous request, because Supabase’s own advisor confirms a policy exists, not that it works. You can do all of this yourself, for free, in about twenty minutes.

Row Level Security (RLS) is the Postgres feature that decides, row by row, who is allowed to read or write a piece of data. When it’s misconfigured on a Supabase-backed app, anyone with your public API URL — which ships in your browser bundle — can query your tables directly and read data that was supposed to be private. This is the most common critical issue we find on AI-built apps, so let’s fix it properly, starting with the free path.

Step 1 — Find which tables are exposed

In the Supabase dashboard, open Advisors → Security Advisor. It will list any table where RLS is disabled outright — start there. Then open the Table Editor and look at every table that holds user or business data: profiles, orders, messages, submissions, anything private. Note which ones have the little “RLS disabled” warning.

But don’t stop at the toggle. The real test is to behave like an anonymous visitor. Your project ref, URL, and anon key are all public (they’re in your client bundle), so you can run this from a terminal:

curl 'https://YOUR_REF.supabase.co/rest/v1/profiles?select=*' \
  -H "apikey: YOUR_ANON_KEY"

# Leaking:  [ { "id": 1, "email": "real@user.com", ... }, ... ]
# Safe:     []            (RLS blocked the read)
# Safe:     401 / permission denied

If real rows come back, that table is readable by the entire internet. If you get an empty array or a permission error, RLS is doing its job on reads (you still need to check writes).

Step 2 — Enable RLS on the table

Open the SQL Editor and turn RLS on for each exposed table. With RLS enabled and no policy, Postgres denies everything by default — which is safe, but will break legitimate access until you add policies in Step 3, so do these together.

ALTER TABLE public.profiles ENABLE ROW LEVEL SECURITY;

Step 3 — Write a policy per operation

A single “enable RLS” is not a fix. You need an explicit policy for each operation your app performs. The most common pattern is “a user can only touch their own rows,” expressed by comparing the row’s owner column to auth.uid() (the ID of the logged-in caller). Here is a complete before/after for a profiles table keyed by a user_id column.

Before — the silent leak

Either RLS is off, or there’s a lazy catch-all policy that a builder generated to “make it work”:

-- DANGER: this satisfies the advisor but blocks nothing
CREATE POLICY "allow all" ON public.profiles
  FOR SELECT USING (true);

USING (true) means “this row is visible for every request” — RLS is technically enabled, a policy technically exists, and your entire table is still public.

After — policies that actually enforce ownership

-- Read only your own row
CREATE POLICY "read own profile" ON public.profiles
  FOR SELECT
  USING (auth.uid() = user_id);

-- Insert only rows you own
CREATE POLICY "insert own profile" ON public.profiles
  FOR INSERT
  WITH CHECK (auth.uid() = user_id);

-- Update only your own row
CREATE POLICY "update own profile" ON public.profiles
  FOR UPDATE
  USING (auth.uid() = user_id)
  WITH CHECK (auth.uid() = user_id);

-- Delete only your own row
CREATE POLICY "delete own profile" ON public.profiles
  FOR DELETE
  USING (auth.uid() = user_id);

Note the two clauses: USING filters which existing rows a query can see or affect; WITH CHECK validates the new values on an insert or update so a user can’t write a row owned by someone else. Public-read tables (say, a published blog post) can keep a deliberate USING (true) on SELECT only — the sin is applying it to private data or to writes.

Step 4 — Verify it actually blocks the request

This is the step that separates a real fix from a false sense of safety. Re-run the exact anonymous request from Step 1. It must now return an empty array or a permission error, not data. Then test the same request while authenticated as a real user and confirm they still see their own rows — you want the leak closed and the app working.

Why this keeps happening on AI-built apps

This isn’t a knock on Lovable or Supabase specifically. Supabase actually does the responsible thing: it ships RLS-by-default on new tables and includes a Security Advisor that warns you when RLS is off. The gap is that an AI builder, prompted to “make the data load,” will sometimes disable RLS or generate a permissive policy to clear an error — and the advisor, which checks for the presence of a policy, stays quiet.

The consequences are documented. CVE-2025-48757 was a Lovable RLS misconfiguration that exposed 303 endpoints across 170 projects. An estimated 70% of Lovable apps fail the anonymous-read RLS check on at least one table. The pattern is consistent enough that if you built with an AI tool and haven’t hand-checked RLS, you should assume a table is open until you’ve run the request in Step 4.

Common mistakes to avoid

• ›Enabling RLS but forgetting writes. A read policy without matching insert/update/delete rules can leave your table writable by anyone — the more dangerous failure of the two.
• ›Leaving USING (true) on private data. RLS enabled, a policy present, and the table still readable by everyone.
• ›Using the service_role key in client code. That key bypasses RLS entirely; it belongs only in server-side code and must never ship in a bundle.
• ›Public storage buckets. RLS on your tables won’t help if an uploads bucket is set to public and lists everyone’s files.

If you’d rather we did it

The free path above is genuinely the right first move — for most apps it’s twenty minutes of work and no cost. If you’d rather not write SQL, or you want a second pair of eyes on a fundraise-critical app, the Fix puts a senior dev on it: we write and test the policies, rotate anything that leaked, and re-scan to show the before/after. And whether you fix it yourself or we do, finish by running the free scan once more to confirm the anonymous request now returns nothing.

FAQ