What Is Supabase?
An open-source Firebase alternative providing a PostgreSQL database, authentication, real-time subscriptions, storage, and Edge Functions. Supabase is the default backend for many vibe-coding platforms (Lovable, Bolt.new) and is widely used in AI-generated applications.
Security Risks
Supabase’s power and flexibility create security risks when used by AI code generators:
- Missing RLS policies: Tables default to unrestricted access; AI rarely enables RLS
- Anon key exposure: The anon key is public by design but requires RLS for security
- Service role key leaks: The admin key in client code gives full database access
- Insecure storage rules: File storage buckets may allow public read/write
- Auth configuration: Default auth settings may not enforce email verification
- Edge Function security: Server functions may lack input validation
- Direct database access: Client can query any table without server middleware
Security Checklist
- Enable RLS on EVERY table (no exceptions)
- Write and test RLS policies for each table (SELECT, INSERT, UPDATE, DELETE)
- Verify the service role key is NEVER in client-side code
- Configure storage bucket policies to restrict file access
- Enable email verification in auth settings
- Set up rate limiting via Edge Functions or middleware
- Use Edge Functions for sensitive business logic
- Audit all database functions for security implications
- Configure proper CORS settings in the Supabase dashboard
- Test by attempting to access other users’ data via the API
Frequently Asked Questions
What is RLS and why is it critical?
Row Level Security (RLS) is PostgreSQL’s built-in access control that restricts which rows each user can access. Without RLS, any user with the anon key can read and write ALL data in a table. With RLS, you define policies like ‘users can only read their own data.’ RLS is the single most important security control in Supabase.
Is the Supabase anon key a security risk?
The anon key is designed to be public – it identifies your project but does not grant special access. Security depends entirely on RLS policies. With proper RLS, the anon key only allows access to data the policies permit. Without RLS, the anon key gives full table access, which is a critical vulnerability.
How do I test my RLS policies?
Use the Supabase SQL editor to test policies. Log in as different users and try to access each other’s data. Use the Supabase client library with different auth tokens. Check that INSERT, UPDATE, and DELETE operations are also restricted, not just SELECT. Consider using pgTAP for automated RLS testing.