Learn the Standard
Supabase Security Surfaces
Apply the PostgreSQL core carefully to Data API, Auth, Storage, views, RPC and Realtime.
Data API and Auth
- Inventory every API-reachable table, view, and function in exposed schemas such as public.
- Publishable/anonymous client keys are safe only with correctly tested grants and RLS; secret/service-role keys never belong in browsers.
- Authenticated means signed in, not staff or administrator.
- Do not use user-editable metadata as an authorization source.
- Treat Supabase-managed Auth schema objects as platform-owned; test any auth.users trigger because failure can block authentication workflows.
Storage is not ordinary table DML
SQL may create reviewed RLS policies on storage.objects and justified supported indexes. Test upload, overwrite, list/read, move, and delete behavior through the Storage API. Database restoration does not restore deleted underlying Storage objects.
Views and RPC functions
Treat a view or RPC in an exposed schema as an endpoint. On applicable PostgreSQL 15+ hosted projects, an API-accessible view intended to inherit underlying RLS must use security_invoker = true. Confirm the hosted PostgreSQL version before using version-sensitive behavior.
Realtime needs its own tests
If the feature uses Postgres Changes, Broadcast, or Presence, document observable tables/topics/payloads, public versus private channel configuration, policies on realtime.messages, and expected revocation behavior for existing connections. SQL catalog inspection does not prove client subscription behavior.