Supabase RLS: A Security Checklist Before You Launch

Supabase is an incredible platform that accelerates development by providing an auto-generated REST API directly on top of your PostgreSQL database. This architecture is powerful, but it completely shifts the security paradigm.

Instead of writing backend endpoints to validate user permissions, you must rely entirely on PostgreSQL Row-Level Security (RLS). If RLS is misconfigured, anyone with your public anon key can read, modify, or delete your entire database.

Use this checklist to secure your Supabase project before launching.

1. Enable RLS on Every Table

By default, newly created tables in Supabase have RLS disabled. This means they are completely public.

Check: Go to the Supabase Dashboard -> Authentication -> Policies, and ensure every table shows "RLS Enabled". Alternatively, run this SQL:

sql
ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;

2. Default to Deny All

When RLS is enabled, the default behavior is to deny all access unless a specific policy grants it. Ensure you have not accidentally created an overly permissive generic policy like true for all operations.

3. Write Explicit SELECT, INSERT, UPDATE, and DELETE Policies

A common mistake is granting ALL privileges based on a simple check. It is much safer to write discrete policies for each operation.

For example, a user might be able to SELECT any post, but only UPDATE or DELETE their own posts.

sql
-- Example: Users can only update their own profiles
CREATE POLICY "Users can update own profile" 
ON profiles 
FOR UPDATE 
USING (auth.uid() = id);

4. Protect Your Service Role Key

The service_role key bypasses RLS completely. It is designed for backend administrative tasks. Check: Ensure the service_role key is NEVER exposed in your frontend code. It should only reside in secure backend environments or Edge Functions.

5. Validate Input in Triggers

RLS handles authorization (who can access data), but it does not handle validation (is the data formatted correctly). Check: If users can insert data directly from the client, use PostgreSQL check constraints or trigger functions to ensure fields like email_address or age contain valid data.

6. Secure Storage Buckets

Supabase Storage also relies on RLS. If you have a bucket for user avatars, ensure policies dictate who can read and upload to that bucket. Check: Verify that your "private" documents bucket does not have a public read policy.

Want CodeAudit to check your repo for this automatically? Join the waitlist.

Frequently Asked Questions

Q: Does RLS affect performance? A: RLS policies add a small overhead to every query. Keep policies simple and avoid complex subqueries within the policy definition to maintain high performance.

Q: Can I test my RLS policies? A: Yes, you can use the Supabase dashboard to simulate queries as different users, or write unit tests using the pgTAP extension. CodeAudit also statically analyzes your migration files to detect missing RLS.

Want CodeAudit to check your repo for this automatically? Join the waitlist.