Supabase Row Level Security: setup, policies, and testing

-- Enable RLS on the table
ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;

-- Users can only see their own data
CREATE POLICY "Users can view own data"
ON your_table
FOR SELECT
TO authenticated
USING ((select auth.uid()) = user_id);

-- Users can only insert their own data
CREATE POLICY "Users can insert own data"
ON your_table
FOR INSERT
TO authenticated
WITH CHECK ((select auth.uid()) = user_id);

-- Users can only update their own data
CREATE POLICY "Users can update own data"
ON your_table
FOR UPDATE
TO authenticated
USING ((select auth.uid()) = user_id);

-- Users can only delete their own data
CREATE POLICY "Users can delete own data"
ON your_table
FOR DELETE
TO authenticated
USING ((select auth.uid()) = user_id);

Important: Use (select auth.uid()) instead of auth.uid() for better performance. The select wrapper prevents re-evaluation on every row.

-- In a local or test environment, simulate a signed-in user
set session role authenticated;
set request.jwt.claims to '{"role":"authenticated","sub":"USER_UUID"}';

-- Assert this user can read their row, but not another user's row
select * from public.your_table;

-- Put repeatable allow and deny assertions in supabase/tests/
-- Then run: supabase test db

Manual testing catches simple cases, but misses edge cases like write access, storage buckets, and RPC functions. For a thorough check, run a scan against your live app.

Wrapping auth.uid() in a SELECT subquery lets Postgres create an initPlan and cache a value that does not change per row. Supabase's performance guidance recommends this pattern for JWT and other stable functions. Also index columns used by policies and measure the real query plan before and after.

It means a table in an exposed schema can be reached through the Data API without row policies. Actual access also depends on Postgres grants. Enable RLS with ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;, revoke operations the role does not need, and add explicit policies for everything that remains allowed.

Tables created through the Supabase Dashboard have RLS enabled by default. Tables created through SQL, migrations, or external tools may not. Include the RLS statement in the same migration that creates each exposed table so the protection is reproducible.

Add ALTER TABLE public.your_table ENABLE ROW LEVEL SECURITY; to the migration, set only the grants each role needs, and create policies for each permitted operation. Revoking default privileges can make new exposure opt-in, but it does not enable RLS by itself.

It creates an event trigger that enables Row Level Security on new tables in the public schema. That is a useful safety net, but it does not create policies or configure least-privilege grants. Keep an explicit ALTER TABLE ... ENABLE ROW LEVEL SECURITY statement in every migration too, so the security state is visible and reproducible.

ALTER TABLE your_table DISABLE ROW LEVEL SECURITY; turns it off for a table. The only legitimate case is read-only public reference data (country lists, public product catalogs), and even then a FOR SELECT TO anon, authenticated USING (true) policy is the safer move. Never disable RLS to fix a permission error; that error is RLS doing its job.

No. Grants decide whether a Postgres role can perform an operation on a table, view, or function. RLS policies then decide which rows that operation can affect. PostgreSQL evaluates grants first, so a secure review must cover both layers.

Add database tests for allowed and denied SELECT, INSERT, UPDATE, and DELETE operations under both anon and authenticated. Use two authenticated users to test cross-user and cross-tenant isolation, then run supabase test db. Vibe App Scanner can also probe the deployed app from an external attacker's perspective.