But speed comes at a cost. As we started using SupaExplorer to audit projects, we noticed a pattern: many apps were misconfiguring their Supabase setup. The anon key in client-side code is fine; it's designed to be public. But we found apps exposing the service_role key (which bypasses RLS), or using the anon key with tables that had no RLS policies at all.
We decided to quantify the problem. Over the past month, we collected launch URLs from five major indie product directories and systematically scanned each one.
- 20,052 URLs Scanned - 2,217 Domains Exposed - 11.04% Exposure Rate - 2,325 Critical Exposures
What's Being Leaked
Not all exposures are equal. Finding a Supabase project URL and anon key in client code is expected, as both are designed to be public. The anon key provides low-privilege access that respects your Row Level Security policies.
The danger is when apps expose the service_role key (or the new sb_secret_... format), the elevated-privilege key meant only for server-side use. Of the 2,960 files flagged, we found credentials that could bypass RLS in a significant portion. We also verified which exposed databases had tables without RLS protection.
I would love to hear your thoughts on this, and how can we generating awareness about this topic.