Thanks, Paul, for the comment. It means a lot to me.
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.
The vast majority of the web apps in those launch directories were built using some sort of AI tool, also there are certain fingerprints you can use to confirm some tools, like Lovable, V0, etc.
Yes, both statements are true, I am building a business around this, but I do also want to reduce the amount of insecure Supabase applications, and that's why I open sourced, and it's also free, my Chrome Extension. Because that's a quick check, any non-technical person can do.
I am currently in communication with many of the sources I used to harvest those sites, so they can warn them, and I also offered a quick API integration that can plugged in during their submission process, so they can warn users right before they launch their apps on those directories. Another option is to get their contact information, but there is no way I can get into their inboxes without being labeled as SPAM :/
Also, another thing I offer for free on my site, is the possibility of running an automated audit on your project, you just connect to Supabase using oAuth. And get a report of what's missing, from there you can either click the "fix in Cursor" or copy results button, and ask your favourite LLM to fix it, or buy my advanced report with the fixes for 5 bucks. But I do offer a free options though.
And, when it comes to community recommendations, I am doing my best, reaching out to dev influencers, posting regularly on /r/Supabase/ (not spamming, providing real value).
Last but not least, Supabase did added a LOT of new features in their dashboard to warn and prevent users from shipping tools unprotected, but the issue is many of these apps were created using CLI, GUI, or Web tools where the user almost never go to Supabase's dashboard, so they never see those warnings :(
Something remarkable happened in 2024-2025: building a full-stack app became easy. Tools like Supabase, combined with AI coding assistants and no-code builders, let solo founders ship production apps in days, not months.
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.
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.