11% of vibe-coded apps are leaking Supabase keys

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.

Related, I believe Supabase already had bad defaults in the name of convenience way before this.

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.

(Supabase CEO)

> 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

Yes, sometimes is hard, and also kinda frustrating when they don't seem to care about their users' data privacy.

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.

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.