supabase-security-basics

# Supabase Security Basics ## Overview Supabase exposes a Postgres database directly to the internet via PostgREST. Every table without Row Level Security enabled is fully readable and writable by anyone with your project URL and anon key — both of which are public. This skill covers the three pillars of Supabase security: key separation (anon vs service_role), RLS policy enforcement, and API surface hardening. ## Prerequisites - Supabase project created (local or hosted) with Dashboard access - `@supabase/supabase-js` installed (`npm install @supabase/supabase-js`) - `SUPABASE_URL` and `SUPABASE_ANON_KEY` environment variables configured - Basic understanding of SQL and Postgres ## Instructions ### Step 1 — Understand the Two API Keys Supabase issues two keys per project. Confusing them is the most common security mistake: | Key | Environment Variable | Exposed to Client? | RLS Behavior | |-----|---------------------|-------------------|--------------| | **Anon key** | `SUPABASE_ANON_KEY` | Yes — browser-safe | Respects all RLS policies | | **Service role key** | `SUPABASE_SERVICE_ROLE_KEY` | **NEVER** expose | Bypasses ALL RLS | The anon key is a JWT that PostgREST uses to determine which RLS policies apply. It is safe to include in client-side bundles — it can only access data that RLS policies explicitly allow. The service role key bypasses every RLS policy and should only ever exist in server-side code (API routes, Edge Functions, cron jobs, migration scripts). ...