How to Add Row Level Security to Supabase (2026)

About 60% of AI-built Supabase apps we scan have at least one table with Row Level Security disabled. Usually it's the main data table (the one that holds every user's records). Anyone with your Supabase URL and anon key can read all of it.

Fixing that isn't hard, but the order of operations matters. Enable RLS the wrong way and you lock out every user instantly. This guide walks through doing it right.

Step 1: Find Every Table Without RLS

Run this in the Supabase SQL Editor. It lists every table in your public schema that doesn't have RLS enabled:

SELECT
  schemaname,
  tablename,
  rowsecurity
FROM pg_tables
WHERE schemaname = 'public'
  AND rowsecurity = false
ORDER BY tablename;

You want this query to return zero rows. If it returns your users, posts, orders, or any other core table, those are unprotected right now.

Step 2: Write Policies First

This is the step most guides skip. RLS starts denying all access the moment you enable it. If you don't have policies ready, your users hit empty tables or 403 errors.

Write policies with RLS still off. They sit dormant until you activate them.

The most common pattern for AI-built apps is user-scoped access: each user can only touch their own rows.

-- SELECT: users can only read their own rows
CREATE POLICY "users_select_own"
ON your_table
FOR SELECT
USING (auth.uid() = user_id);

-- INSERT: users can only add rows for themselves
CREATE POLICY "users_insert_own"
ON your_table
FOR INSERT
WITH CHECK (auth.uid() = user_id);

-- UPDATE: users can only change their own rows
CREATE POLICY "users_update_own"
ON your_table
FOR UPDATE
USING (auth.uid() = user_id)
WITH CHECK (auth.uid() = user_id);

-- DELETE: users can only delete their own rows
CREATE POLICY "users_delete_own"
ON your_table
FOR DELETE
USING (auth.uid() = user_id);

Replace your_table with your actual table name and user_id with whatever column stores the owner's user ID.

Step 3: Enable RLS Atomically

Once policies exist, enable RLS in the same transaction. This is the key move: if anything fails partway through, the whole operation rolls back and nothing breaks.

BEGIN;

-- Enable RLS
ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;

-- Force RLS to apply even to the table owner
ALTER TABLE your_table FORCE ROW LEVEL SECURITY;

-- Verify policies are there before committing
SELECT policyname, cmd FROM pg_policies WHERE tablename = 'your_table';

COMMIT;

The FORCE ROW LEVEL SECURITY line is important if you connect to Supabase using the postgres superuser (some local dev setups do). Without it, the table owner bypasses all your policies.

If you have multiple tables to protect, run this pattern for each one separately, so a problem with one table doesn't cascade.

Step 4: Verify the Policies Work

Don't just check that your data appears. Check that someone else's data doesn't.

Test in SQL Editor:

-- Simulate a specific authenticated user
SET LOCAL request.jwt.claims TO '{"sub": "your-user-uuid", "role": "authenticated"}';

-- Should return only that user's rows
SELECT * FROM your_table;

-- Should return nothing
SELECT * FROM your_table WHERE user_id = 'some-other-user-uuid';

Test in your app:

1. Log in as User A
2. Note the ID of a row owned by User B (get it from the Supabase Table Editor)
3. Try to fetch that row directly via your app
4. You should get an empty result or 403, not the data

If you're using the Supabase client library, you can also check this in the Supabase Dashboard under Authentication > RLS Policies and use the built-in policy tester.

Step 5: Handle Edge Cases

A few patterns come up in almost every AI-built app:

Public tables (readable by anyone, like a products catalog):

CREATE POLICY "public_read"
ON products
FOR SELECT
USING (true);

ALTER TABLE products ENABLE ROW LEVEL SECURITY;

The profiles table (users need to read their own profile, and sometimes others' public info):

-- Anyone can read public profile fields
CREATE POLICY "profiles_public_read"
ON profiles
FOR SELECT
USING (true);

-- Users can only update their own profile
CREATE POLICY "profiles_update_own"
ON profiles
FOR UPDATE
USING (auth.uid() = id)
WITH CHECK (auth.uid() = id);

ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;

Storage buckets (people forget these have separate policies):

In the Supabase Dashboard, go to Storage > Policies. A "private" bucket still needs explicit policies on storage.objects to work correctly. Without them, even authenticated users get 403s on uploads and downloads.

What the Scanner Sees

When CheckYourVibe scans your Supabase app, the most common finding is a table with RLS disabled and the anon key accessible from the client. We see this on roughly 60% of scanned AI-built Supabase projects.

The specific finding looks like this:

This isn't hypothetical exposure. It's a live endpoint. The Supabase REST API for your project is publicly accessible, and the anon key is in your frontend bundle.