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.
About this: "- LLM generated code: benchmark and evals to measure which popular programmatic LLMs recommend the right approach.", check this out https://cset.georgetown.edu/wp-content/uploads/CSET-Cybersec...
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 :(
In the PostgREST docs schema isolation is explained in detail: https://docs.postgrest.org/en/v12/explanations/schema_isolat...
By default, Supabase exposes the public schema directly. This means tables created in the standard public schema are immediately accessible as API endpoints.
The truth is there's just no way around learning about the underlying technology or building up the necessary experience if one wants to create robust and secure software and products. No amount of AI will solve it, sorry, it's a harsh truth.
> 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.