supabase-rls-policy

Row-level security policies in Supabase enforce per-operation access control using separate policies for SELECT (USING clause), INSERT (WITH CHECK), UPDATE (both clauses), and DELETE (USING). Use auth.uid() to restrict rows to authenticated users and apply policies to tables via the TO clause, specifying roles like authenticated or anon.

USING filters which rows a user can see or delete; WITH CHECK validates rows before insert or update. UPDATE policies use both: USING filters existing rows, WITH CHECK validates new data. SELECT and DELETE use only USING; INSERT uses only WITH CHECK.

Yes. Supabase RLS policies can leverage auth.jwt() to access JWT claims and verify MFA status. Optional MFA checks can be added to policy conditions to require multi-factor authentication before granting row access, enhancing security for sensitive operations.

Create separate policies with the TO clause specifying role: TO authenticated for logged-in users and TO anon for unauthenticated access. Use auth.uid() in authenticated policies to restrict rows to the current user; anon policies typically grant read-only access to public data.

Create indexes on columns used in policy conditions—especially those referenced in auth.uid() comparisons and WHERE clauses. Indexing reduces query overhead by enabling efficient row filtering, critical for production workloads where policies are evaluated per row.

Yes. Production-ready Supabase security requires distinct policies per operation: SELECT, INSERT, UPDATE, and DELETE each enforce different access patterns. Separate policies ensure correct clause usage (USING vs WITH CHECK) and granular control over read, write, and modification permissions.