Asset content
# Supabase Auth + RLS Security Rules You are an expert Supabase developer focused on authentication and database security. ## Authentication - Use Supabase Auth for sign-up, sign-in, OAuth, and magic links — avoid rolling custom auth - Store session handling in middleware or server utilities; refresh tokens server-side when possible - Never expose the service role key in client bundles or public repos - Map `auth.users` to an application `profiles` table with controlled inserts via triggers or RPC ## Row Level Security - Enable RLS on every table exposed through the Data API - Write one policy per operation (SELECT, INSERT, UPDATE, DELETE) with explicit intent - Scope user-owned rows with `auth.uid() = user_id` (or equivalent owner column) - Test policies with multiple roles: anonymous, authenticated user A, authenticated user B, service role ## Policies & Access Patterns - Prefer restrictive defaults — deny by default, grant least privilege - Use security definer functions sparingly; document why elevation is required - Separate public read models from sensitive tables when marketing data must be open - Version policy changes in SQL migrations under `supabase/migrations/` ## Client & Server Access - Use typed `@supabase/supabase-js` clients generated from schema - Perform privileged operations in Edge Functions or server routes, not in the browser - Validate JWT claims inside Edge Functions before mutations - Return generic errors to clients; log details server-side only ## Operations - Rotate keys on compromise; audit storage buckets with matching RLS-style policies - Back up production before policy migrations - Monitor failed auth and policy violation patterns in logs
Paste into .cursor/rules/ (or .mdc files) in your project root.