An independent security researcher scanned 100 random Supabase projects and found 22 with publicly accessible user data due to misconfigured row-level security. It's a reminder that backend-as-a-service platforms are only as secure as their default configurations.
Supabase markets itself as "the open source Firebase alternative" that developers love. Low-code backends mean you can ship faster. You don't need to be a database expert to build a full-stack app. The accessibility is genuinely impressive.
But low-code backends mean developers who might not understand security are managing user data. This is the accessibility vs. security tradeoff playing out in real time.
The audit found five primary vulnerability patterns. The most common: 47% of leaky projects had Row-Level Security (RLS) completely disabled. Tables created without RLS retained default anonymous CRUD permissions, meaning anyone could read, write, update, or delete data without authentication.
Another 18% had RLS enabled but with overly permissive policies — rules that evaluated to true for all users or explicitly granted access to anonymous roles. It's like putting a lock on your door but giving everyone the key.
12% had SECURITY DEFINER functions left executable by anonymous users. These functions run with owner privileges, granting "owner-level access to whatever the function touches." That's a privilege escalation vulnerability waiting to happen.
8% had public storage buckets without proper list guards, allowing anonymous users to discover and download files uploaded by other users. And 5% had committed their service-role keys to public GitHub repositories, which completely bypasses RLS since those credentials have unrestricted database access.
The researcher's key recommendation: "Don't trust the metadata" or dashboard indicators. Instead, "issue an actual anonymous SELECT against your tables and see what comes back." Verify actual behavior rather than relying on configuration checkmarks.
Supabase changed their defaults on May 30, 2026, but legacy projects remain vulnerable until October 30, 2026. That's a four-month window where projects created before the change need manual fixes.
This isn't a Supabase-specific problem. Every platform that abstracts away complexity creates opportunities for misconfiguration. AWS S3 buckets leak data. MongoDB instances leak data. Firebase projects leak data. The pattern is always the same: defaults that prioritize ease of use over security, plus developers who don't realize they need to lock things down.
I've built with these tools. I understand the appeal. You can ship an MVP in a weekend. You don't need to manage infrastructure. The developer experience is smooth.
But the technology is only as secure as the defaults and the developers using it. When 22% of random projects are leaking user data, that's a systemic problem that better defaults alone won't solve.
