Supabase RLS: The Mistakes Every Guide Skips

-- 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.

-- Test as anonymous user (should return 0 rows)
SELECT * FROM your_table;

-- Or use the Supabase Dashboard:
-- Authentication → Policies → Test your policies

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

Wrapping auth.uid() in a SELECT subquery tells Postgres to evaluate the function once per query instead of once per row. On a 100K-row table that's the difference between a 5ms policy and a 5-second policy. Supabase's own performance docs recommend this pattern. The same applies to auth.role(), auth.jwt(), and current_setting(). If you have the auth_rls_initplan warning on a Supabase project, this is the fix.

It's the warning banner Supabase shows when one or more tables in the public schema have RLS turned off. Because tables in public are exposed via the auto-generated REST API, any table without RLS is readable (and often writable) by anyone holding your project's anon key. The fix is one line per flagged table: ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;. This is the misconfiguration that CVE-2025-48757 exploited at scale.

No. Tables created via SQL or the Table Editor have RLS off by default. Supabase ships an “Enable RLS on new tables” project-level toggle, but you have to turn it on yourself. This default is exactly why 10.3% of analyzed Lovable apps in CVE-2025-48757 were leaking data through the anon key.

In the dashboard: Authentication → Policies → toggle “Enable RLS on new tables.” This forces every newly-created table in the public schema to start with RLS enabled. It doesn't add policies for you — you still need to write the access rules — but it removes the default “open to the world” state. Highly recommended on every new Supabase project.

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.

Left sidebar → Authentication → Policies. This screen lists every RLS policy across your project grouped by table, surfaces the project-level “Enable RLS on new tables” toggle, and shows the schema-level RLS status. If a table has RLS enabled but no policies, you'll see “no policies” — meaning the table is locked even for authenticated users.

Manually: in the SQL Editor, switch your role to anon and try SELECT * FROM your_table on each table. Programmatically: Vibe App Scanner reads your Supabase config from your live app frontend and tests every table for read/write access plus storage buckets, RPC functions, and edge functions. Starter Scan is $9, results in 2-3 minutes. Or use the free RLS Checker tool for a quick sanity check.