A friend recently came across a project with no RLS and described it as "a once in a lifetime fuckup, a career defining moment, you could shitcan them but they wont learn how to fix it, either way they need adult oversight".
And once you find some dumb low-hanging fruit like that, you usually discover that the vibe-coded ignorance is fractal, especially with TypeScript projects where people assume that you define something in an interface with a given type that the user will always supply that - and your user will always be the app you wrote - and duck-typing doesn't exist.
Maybe worth scanning the various Android app stores? It's incredibly depressing.
For Android/iOS, I know those are even worse, but it's tricky to get the data, might be easier to get and decompile the APKs though.
xyborg•2w ago
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.
alexhans•2w ago
- We want to build a business opportunity around auditing.
- We want to reduce the amount of insecure Sugabase apps.
They align somewhat but decisions may vary based on your lens when deciding how much weight to put for watch.
- IANAL, I assume you can or have assesed legal considerations around passive/active/automated scanning of this nature.
- In a direct world you could communitate the fix automatically to the right target for all your finds and track whether they fix the issue (audit periodically at a non spammy/cost inducing frequency)?
- In the general sense I'd try to estimate where I think the error manifests itself to attempt different solutions and find ways to measure those, where am I fixing the problem?
- Is there something in the core tools (I don't really know Supabase) that would make it less likely for a developer following an outdated or malicious tutorial to do the insecure thing?Security is always a fun problem to think about once you start thinking about it from an economics lens of rational actors with limited knowledge and varying incentives.
xyborg•2w ago
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 :(
sureglymop•2w ago
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.
kiwicopple•2w ago
> 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
xyborg•2w ago
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.