HOW SECURE IS SUPABASE? (B)

Rating: B

Supabase is safe at the platform layer. The score drops because the defaults leak data — the anon key ships to the browser, and new tables don’t get RLS automatically. Most Supabase apps we scan are vulnerable for this reason alone.

Top failure modes

1. Missing RLS on public tables — Every new table is accessible to the public anon key until you add policies. Starter kits rarely remind you.

2. Service-role key in client code — Bypasses RLS entirely. We find this in ~4% of apps we scan, and it’s always a full database takeover.

3. Storage buckets set to public — One checkbox in the UI. Makes every uploaded file publicly readable.

How to make Supabase safer

1. Treat the defaults as a starting point, not a secure configuration.
2. Audit each failure mode above against your specific deployment.
3. Run an automated scan against the deployed app — UI signals rarely surface the backend issues.
4. Re-scan after every material change (new table, new Edge Function, new env var).

For the full analysis of Supabase’s platform, defaults, and the failure modes we find on real deployments, see Is Supabase Safe?.

Related

• Supabase RLS Checker
• Is Supabase Safe?

FAQ

Is Supabase secure by default?

No. The platform infrastructure is secure, but new projects ship with the anon key exposed to the browser and no RLS on newly created tables. Security depends entirely on you adding Row Level Security policies to every public table.

Can attackers read my Supabase database?

Only if RLS is missing or misconfigured. The anon key alone does nothing if every table has policies that scope rows to the caller via auth.uid(). Without RLS, the anon key is effectively a full read/write key to your database.

What’s the most common Supabase security mistake?

Adding a permissive ‘USING (true)’ policy to ‘make RLS work’ and then shipping. This is functionally identical to having RLS disabled — any anon user can read the whole table.