Supabase Security Checklist
Secure your Supabase project by verifying: RLS enabled on every table with proper policies, service role key never in client code, email confirmation enabled, redirect URLs whitelisted, IP allowlists configured, and Security Advisor recommendations addressed.
Why this matters
Supabase is the most common backend for AI-built apps — Lovable, Bolt, and Replit all integrate with it. Its security model is powerful but requires explicit configuration. The 2025 Security Retro report highlighted RLS misconfiguration as the most common vulnerability.
What's at stake
Supabase exposes your database through a public API. Without RLS, anyone with your project URL and anon key can query every table. Security researchers have found hundreds of AI-built apps vulnerable for this exact reason.
Your checklist.
RLS is enabled on every table in the public schema
CriticalRun: SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public'; Every table with user data must show 't' (true). Tables created outside the dashboard may have RLS disabled.
RLS policies use auth.uid() and include WITH CHECK
CriticalPolicies must use auth.uid() for user identification (never client-provided IDs). INSERT and UPDATE policies need WITH CHECK clauses to prevent users from creating data they should not own.
Service role key is only used server-side
CriticalThe service role key bypasses all RLS. Use it only in Edge Functions or server-side API routes. Supabase automatically revokes service role keys detected in public GitHub repos.
Email confirmation is enabled in Auth settings
ImportantWithout email confirmation, anyone can create accounts with fake emails. Enable it in Authentication > Settings to prevent spam and fake signups.
Redirect URLs are whitelisted
ImportantOnly add trusted domains to the redirect URL allowlist. This prevents open redirect attacks that could be used in phishing.
Security Advisor recommendations are addressed
ImportantSupabase provides Security Advisors that scan for misconfigurations. Run them regularly and address all findings, especially those related to RLS and key management.
Policies have been tested by impersonating roles
ImportantUse the SQL editor to test RLS policies as anon, authenticated, and specific user roles. Verify that each role can only access the data it should.
IP allowlists are configured for direct database access
RecommendedIf you connect directly to the database (not through the API), configure IP allowlists to restrict access to trusted addresses.
Backups are enabled and tested
RecommendedPro plans include daily backups with 7-day retention. For critical data, enable Point-in-Time Recovery (PITR) for second-level granularity. Test restoration periodically.
Comprehensive Supabase security verification
- Automated RLS audit across all tables and policies
- API key exposure detection in connected frontend apps
- Continuous monitoring for security configuration changes
Frequently asked questions.
Tables created through the Supabase dashboard have RLS enabled by default. But tables created through migrations, AI-generated code, or external tools may not. Always verify after creating new tables.
Enabling RLS with proper policies on every table. Without RLS, your anon key (which is publicly visible in frontend code) grants full read/write access to unprotected tables.
Supabase automatically scans public GitHub repositories for exposed service role keys and revokes them. You can also search your frontend codebase and deployed JavaScript bundle for the key string.
Yes. Regardless of which tool you use to build your frontend, your Supabase backend needs the same security configuration. RLS, key management, and auth settings apply to every Supabase project.