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.
> The danger is when apps expose the service_role key (or the new sb_secret_... format)
Fwiw, the new secret keys are automatically revoked if they are pushed to github, and github is progressively rolling out push protection - to prevent them getting pushed in the first place. Of course, not everyone uses github
People disabling RLS, or making RLS a simple pass-through, is a battle we are constantly fighting. We have made good strides here over the past 12 months:
https://supabase.com/blog/supabase-security-2025-retro
- event triggers to enforce RLS on all tables
- lints to scan for insecure rules
- ai to write secure policies (if they are too lazy or confused to do it themselves)
- big red labels when a table is exposed
- weekly emails with security alerts
- dashboard alerts and security advisors
- contractually requiring Vibe coding platforms to expose our Security Advisors if they are integrating with us
- red teaming customers that have egregious issues (this has been surprisingly effective, just harder to scale up)
I appreciate you creating this tool - as you can see we are also “tooling up” as much as we can. If there are any other things that you think we are missing let me know and we will prioritize it
We will be introducing new AuthZ patterns this year so I’m hoping that will also help
I also published a recap of what Supabase has been doing over the last year to improve all of this: https://supaexplorer.com/dev-notes/supabase-security-2025-wh... I now think it makes sense to include it in the top notice I added to my report, next to where it says "Supabase is NOT insecure by design," since key revocation was one of those changes.
I believe we all know, at least the ones who care about this topic, that you've been making a lot of improvements and adding extra annoying (but justified!) UI features to make this issue more prominent and push people to fix it.
"- contractually requiring Vibe coding platforms to expose our Security Advisors if they are integrating with us" - I like this, and I honestly would love to see those platforms truly enforce it, even when the user is just building an MVP not ready for production, which most of the time ends up there.
And definitely, any improvement in authz will be very helpful, especially if it can be pushed via external coding platforms.