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.
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.
A quick reaction is that there's almost 2 different intents that need to be considered here:
- 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?
- LLM generated code: benchmark and evals to measure which popular programmatic LLMs recommend the right approach.
- Community recommendations: Make your case within the community to modify the appropriate tutorials.
- 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.
> 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:
- 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
Finally somebody built this, the problem is that the people who don't know won't think of using this tool.
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.
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.
xyborg|1 month 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.
sureglymop|1 month 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.
alexhans|1 month 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.
kiwicopple|1 month 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
quesomaster9000|1 month ago
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.
xyborg|1 month ago
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.
evanreichard|1 month ago
xyborg|1 month ago
unknown|1 month ago
[deleted]