How to test Supabase RLS before you ship

1. USING (true) on a table with private data

USING (true) means "every row matches". It is fine for a public catalog such as products or prices. On a table with emails, orders, messages or anything per-user, it hands the whole table to anyone holding the anon key. On an UPDATE or DELETE policy it is worse: any client can change or wipe every row.

create policy "Profiles are viewable"
  on profiles for select
  using (true);

create policy "Users read own profile"
  on profiles for select
  to authenticated
  using ((select auth.uid()) = id);

2. INSERT policy written with USING instead of WITH CHECK

USING filters rows that already exist. New rows are checked with WITH CHECK. Postgres rejects an INSERT policy that has a USING clause ("only WITH CHECK expression allowed for INSERT"), so the migration fails and every statement after it in the same file is not applied. That can leave RLS enabled with no working insert policy, or leave later policies missing entirely.

create policy "Users insert own todos"
  on todos for insert
  using (auth.uid() = user_id);

create policy "Users insert own todos"
  on todos for insert
  to authenticated
  with check ((select auth.uid()) = user_id);

3. Storage bucket policies scoped only by bucket

Storage uses RLS on storage.objects. A policy that only checks bucket_id applies to every file in that bucket, whoever uploaded it. For a private bucket (invoices, documents, IDs) that means any caller can list and download all files; for an UPDATE or DELETE policy it means any signed-in user can overwrite or delete other people's files.

create policy "Users can delete files"
  on storage.objects for delete
  to authenticated
  using (bucket_id = 'documents');

create policy "Users delete own files"
  on storage.objects for delete
  to authenticated
  using (
    bucket_id = 'documents'
    and (storage.foldername(name))[1] = (select auth.uid())::text
  );

-- upload with: supabase.storage.from('documents').upload(`${user.id}/${file.name}`, file)

4. Service-role key in client code

The service-role key bypasses RLS completely. If it reaches the browser, every policy above stops mattering. The usual ways it leaks: a NEXT_PUBLIC_ prefix on the variable, importing an admin client into a 'use client' component, or pasting the key straight into source.

'use client';
import { createClient } from '@supabase/supabase-js';

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY!
);

// lib/supabase/admin.ts
import 'server-only';
import { createClient } from '@supabase/supabase-js';

export const supabaseAdmin = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
);
// Only call this after checking who the caller is.

5. Foreign key to auth.users without ON DELETE

This one is not a leak, but it breaks a feature you need for privacy requests: deleting an account. If a table references auth.users without an ON DELETE rule, deleting a user who owns rows there fails with a foreign key violation.

user_id uuid references auth.users(id)

user_id uuid references auth.users(id) on delete cascade

Quick checklist

• RLS is enabled on every table in the public schema.
• The anon key returns no rows from private tables.
• User A cannot read, update or delete user B's rows or files.
• All migrations apply cleanly from scratch.
• The service-role key is not in any browser bundle or NEXT_PUBLIC_ variable.
• Deleting a test user with data succeeds.

Check your own repo

Public repositories scan free. Paste a GitHub URL on the dashboard and every finding comes with the file, the line and a fix.