What are Supabase security best practices?

The best practices specific to Supabase (not generic OWASP)

Every "security best practices" list tells you to use HTTPS and rotate keys. Those are table stakes. The list below is what actually matters for Supabase apps, based on the risks that appear in real Supabase deployments.

1. ALTER TABLE name ENABLE ROW LEVEL SECURITY; on every table

*Why:* Any table without RLS enabled is fully exposed via the public API. *Do this:* ALTER TABLE name ENABLE ROW LEVEL SECURITY; on every table.

2. Never use service_role in frontend

*Why:* The service_role key bypasses all RLS and grants admin access. *Do this:* Never use service_role in frontend. Keep it server-side only. Rotate if exposed.

3. Use (select auth

*Why:* Policies that allow more access than intended (e.g., any authenticated user). *Do this:* Use (select auth.uid()) = user_id pattern. Test policies with different contexts.

4. Add auth

*Why:* Database functions callable without authentication. *Do this:* Add auth.uid() IS NOT NULL checks at the start of all functions.

5. Configure storage policies to require authentication and ownership

*Why:* Storage buckets without policies allow public read/write. *Do this:* Configure storage policies to require authentication and ownership.

Supabase-specific: audit every table for RLS before every deploy

The failure mode in Supabase + Supabase apps is always the same: a table gets added during a feature push, RLS never gets turned on, the full table becomes queryable via the anon key. Bake a pre-deploy check: `select tablename from pg_tables where schemaname = 'public' and not rowsecurity` — the result must be empty.

Verification

Even perfect best practices don't prove themselves — the only way to confirm the list above is implemented is to scan a deployed Supabase app. VAS probes each of rls policies, service key exposure, rpc functions, auth configuration by actually attempting the attack, not just reading headers or docs.