RLS Policy

Detailed Explanation

An RLS Policy (Row-Level Security Policy) is a rule you set on a database table in Supabase that controls who can access which rows of data. It's the security guard for your data.

Each policy targets one operation: SELECT (read), INSERT (create), UPDATE (edit), or DELETE (remove). You can have multiple policies per table. A row must match at least one policy for the operation to succeed.

Common policy patterns:

• USING (true) → Anyone can perform this operation (public access)
• USING (auth.uid() = user_id) → Only the row's owner can access it
• USING (auth.role() = 'authenticated') → Any logged-in user can access it
• WITH CHECK (auth.uid() = user_id) → For INSERT/UPDATE, ensures the user_id matches the authenticated user

Why RLS policies matter for debugging:

The trickiest thing about RLS is that it fails silently. When a policy blocks a query, Supabase doesn't throw an error — it returns an empty array []. Your code runs perfectly, the response comes back with status 200, but the data is empty. This is the most common bug in Chapter 4.

To debug RLS issues:

1. Check the Network Tab — if you see 200 with empty data, it's likely RLS
2. Check the browser console for any error messages
3. Open Supabase Dashboard → Authentication → Policies
4. Ask Claude Code to review your policies

Related: Row Level Security, Table (Database), Supabase, Authentication, Status Code, Network Tab, Logging

RLS policies are the mechanism through which Authorization is enforced at the database level in Supabase.