The Supabase Security Checklist for Production Apps (2026)
Quick answer
A production Supabase checklist, in exploit order: enable and force RLS on every public table with per-user scoped policies; keep the service_role key server-side; verify auth redirect URLs and rate limits; scope CORS; disable anonymous sign-ups unless needed; and audit pg_policies monthly. Most breaches come from the first two items.
Tier 1 — gets exploited (do first)
These are the misconfigurations we find in the wild:
- RLS enabled on every table in public schema; force RLS on sensitive tables.
- Policies scoped with auth.uid() / auth.jwt() — no using(true) on private data.
- service_role key only in server-side env vars; rotated if it ever appeared client-side.
- anon/publishable key treated as public — design policies assuming anyone holds it.
Tier 2 — auth configuration
The settings most teams never open:
- Site URL and redirect URLs allowlisted in Auth settings — no wildcards.
- Email confirmations enabled; anonymous sign-ins disabled unless the product needs them.
- Rate limits and captcha on auth endpoints for public launches.
- JWT expiry kept short; refresh token rotation on.
Tier 3 — network and ops
Harder to exploit, cheaper to fix now:
- CORS on any custom API scoped to your domains.
- Network restrictions / IP allowlists if your database allows it.
- Backups verified by actually restoring one.
- A monthly audit: select * from pg_policies — diff it against what you expect.
Make it repeatable
A checklist you run once decays. The projects that stay safe treat this as a recurring scan, not a launch task — every new table, function, and key is a fresh chance to regress. Automate the sweep, review the findings, approve the fixes.
StackShield automates Tier 1 and Tier 2 checks against your live project and re-runs them on a schedule. The Production Readiness PDF (Starter and Pro) covers the rest with your team. Start free.
Run a free scan