Am I Hackable?
Back to Learn

Supabase Security Checklist for Vibe Coders

Benji··3 min read

The short version

Supabase is a powerful backend-as-a-service built on PostgreSQL. It gives you a database, authentication, real-time subscriptions, and auto-generated REST APIs. It's also one of the easiest platforms to misconfigure if you don't understand how its security model works.

The core thing to understand: your Supabase database is directly accessible from the internet. The only thing protecting it is your configuration.

The anon key is public

Your Supabase project has two keys:

The Supabase documentation on API keys is clear: the anon key is safe to expose in client-side code, but only if you have proper RLS policies in place.

The checklist

1. Enable RLS on every table

This is non-negotiable. When you create a new table, RLS is off by default. That means anyone with your anon key can read and write every row.

ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;

Do this for every table. No exceptions. See the Supabase RLS guide for details.

2. Create explicit policies

RLS without policies means no access at all (except for the table owner). You need to create policies that define who can do what.

-- Users can only read their own data
CREATE POLICY "Users read own data" ON profiles
  FOR SELECT USING (auth.uid() = user_id);

-- Users can only update their own data
CREATE POLICY "Users update own data" ON profiles
  FOR UPDATE USING (auth.uid() = user_id);

Think about each table: who should be able to SELECT, INSERT, UPDATE, DELETE? Write a policy for each.

3. Never expose the service_role key

The service_role key bypasses RLS entirely. It has full access to everything. If this key appears in your frontend code, in a public repo, or in client-side environment variables, your entire database is compromised.

Use it only in:

4. Secure your Edge Functions

If you're using Supabase Edge Functions, make sure they:

5. Lock down database functions

If you've created PostgreSQL functions, review their permissions. By default, functions can be called by anyone. Restrict access:

REVOKE EXECUTE ON FUNCTION your_function FROM public;
REVOKE EXECUTE ON FUNCTION your_function FROM anon;
GRANT EXECUTE ON FUNCTION your_function TO authenticated;

6. Check your storage policies

Supabase Storage also uses RLS-style policies. If your storage buckets are public, anyone can upload files. Check your storage policies and make sure only authorized users can upload or access sensitive files.

7. Enable email confirmation

By default, Supabase can be configured to skip email confirmation. For production, enable it. Otherwise, anyone can create accounts with fake emails.

8. Set up rate limiting

Supabase applies some rate limiting by default, but for sensitive operations (password reset, signup), you may want additional limits. Consider using Edge Functions with custom rate limiting for critical endpoints.

Common mistakes

"I'll add RLS later." No. Add it now. The moment your project is deployed, your database is on the internet. "Later" means "after someone has already scraped your data."

Using the service_role key in the frontend because RLS was blocking something. If RLS is blocking a request, it means your policy is working. Fix the policy, don't bypass the security model.

Forgetting about realtime subscriptions. RLS applies to realtime too. But if your policies aren't right, users might receive real-time updates for rows they shouldn't see.

Not testing as an unauthenticated user. Open an incognito window. Open the browser console. Try to access your Supabase API with just the anon key and no auth token. If you get data back, your RLS is broken.

Check your site

Want to know if your site has this issue? Scan it now and find out in 60 seconds.

Frequently Asked Questions

Is Supabase secure by default?
Supabase provides the tools for security (RLS, auth, policies), but you have to configure them. New tables have RLS disabled by default. If you don't enable it and set policies, your data is publicly accessible.
Is the anon key secret?
No. The anon key is designed to be used in frontend code. It's public. Security comes from RLS policies, not from keeping the anon key secret.
Can someone access my Supabase database directly?
Yes. Anyone can make requests to your Supabase API using the project URL and anon key. RLS policies are the only thing standing between them and your data.

Your AI writes the code. We find what it missed.

Paste your URL. Security audit in 60 seconds.

Scan my app