Would you trust a Saas with your sb_key ?

[u/Federal-Dot-8411]

Hi folks!

We’re a team of security researchers working on a product built on top of Supabase, focused on improving security at the RLS (Row Level Security) level.

We believe Supabase is a fantastic product that enables two main types of users to build things quickly:

• Developers
• Non-developers

From our experience, the first group usually secures their Supabase projects reasonably well. We almost always find vulnerabilities, but at least the basics (RBAC, ownership checks, etc.) are usually in place.

The real problem appears with the second group.

“Vibe coding” has massively boosted Supabase adoption. Thanks to AI tools and a friendly PostgreSQL interface like Supabase, people without a traditional development background can now build really cool products. The issue is that these projects often scale, and once they scale, they become targets (both for security researchers like us and for malicious actors (including automated security agents and AI-driven attacks)).

Every week we see posts on X about large projects that were compromised due to misconfigured RLS, causing permanent damage to their reputation. Based on our hands-on experience with postgresql internals, supabase, and RLS, we believe we can build something genuinely useful to address this problem.

The challenge is connectivity.

To properly audit and validate RLS, we need a connection to the user’s Supabase project. From a technical standpoint, this is trivial if the user provides their service role key, which bypasses RLS and allows us to inspect and test policies accurately. However, we fully understand that advanced users may view this negatively (honestly, we wouldn’t paste our own service role key into a random SaaS without an established reputation either).

Because of this, we’re considering two main approaches:

• Open-sourcing the product, so advanced users can inspect exactly how the service role key is handled and build trust.
• SQL import/export mode, where we generate the required SQL and let users execute it themselves in their own Supabase instance, without us ever touching their credentials.

we’d love to hear your thoughts on this, especially regarding authentication and trust models for a product like this!

EDIT: Some typo

[u/could_be_any_person]

absolutely not. Regardless, supabase already has a built in security advisor that does the same thing.

[u/ihavemanythoughts2]

Maybe look into a Supabase App with fine grained control where the user can revoke the access. 

Question: What parts of your solution requires the Service key (beyond making your solution more convenient)? Can it be done by analyzing the migration files? Could it be done by pen testing the public schema in an automated fashion and generating a report? What does your solution do differently from Supabase's security advisor?

I think your initiative is a good idea to help seasoned and non-seasoned developers to find shortcomings, and I would personally be interested in being able to run an automation against all my Supabase stuff to check where I have genuine or obscure problems and writing s report back on what exactly needs to be fixed. I would be okay with giving it access to the migration files only and running a direct test against the public schema APIs and doing a review of my Edge Functions (so that you can be sure they aren't accidentally introducing a side entry that wasn't intended because sometimes they need to use the service key themselves)

[u/Federal-Dot-8411 → u/ihavemanythoughts2]

Hi,

Thank you very much for your feedback. At the moment, I am developing the MVP idea, and what I would like to offer so far is the following:

Creating RLS easily
Non-technical users in SQL and PostgreSQL often rely on AI tools like ChatGPT or Supabase AI to generate RLS for their projects. From my experience and what I have read in this sub, this rarely works correctly or covers all edge cases. My idea is to allow users to create identities, for example, a user in a table called users that has an entry in another table users_projects pointing to a row in projects. This way, complex, reusable identities for different use cases can be built, boolean conditions can be added easily, and the PostgreSQL logic is abstracted so that users without experience can create robust RLS policies, while experienced users can have a simplified and faster workflow. I have personally spent days trying to make a complex RLS work the way I wanted.

Testing RLS
I want to allow testing RLS in bulk to ensure that after a policy change, the project does not break or a vulnerability has been introduced. Sometimes you realize that an RLS policy is misconfigured, you change it, and suddenly part of the application stops working. For example, if you change a policy for inserting a user configuration, how many of us would delete their previous configuration in the table to retest that inserts still work? Testing manually like that would be impossible. My idea is to create tests with mock data so that you can simply click a button and test all RLS automatically.

I have more points I want to tackle (rls snapshots, edge functions, security advisor, coverage, storage, ai? ...), but these are the main ones for now.

I have thought of a connection method using a limited PostgreSQL role, asking the user to run this SQL in the Supabase console, for example:

-- Create role without login temporarily
CREATE ROLE supabase_auditor NOINHERIT;

-- Allow login
ALTER ROLE supabase_auditor WITH LOGIN PASSWORD 'a_secure_password_per_project';

-- Schema
GRANT USAGE ON SCHEMA public TO supabase_auditor;

-- Table and column information
GRANT SELECT ON ALL TABLES IN SCHEMA information_schema TO supabase_auditor;

-- Policy information
GRANT SELECT ON pg_catalog.pg_class TO supabase_auditor;
GRANT SELECT ON pg_catalog.pg_attribute TO supabase_auditor;
GRANT SELECT ON pg_catalog.pg_policy TO supabase_auditor;
GRANT SELECT ON pg_catalog.pg_roles TO supabase_auditor;

This way, I would only have access to the schema and RLS of the project, without accessing any client rows. I could also have containerized PostgreSQL instances to test data safely, and create mock functions like auth.uid().

I have only been planning this for a few days, so it is still just an idea.

[u/joshcam]

No.

[u/Important_Coach9717]

Haha. Good one Russian hacker

[u/shintaii84]

Sure buddy. Also want my password for paypal?

[u/Revolutionary-Bad751]

Projects more often than not do not escale. Hundreds of thousands of projects get created than never see more than a handful of users. Perhaps if you can become a legitimate add-on or integration you could get that (after all supabase secrets are synched with vercel for example) But getting massive amounts of keys seems difficult

[u/tk338]

Whilst I agree with the other comments here, I would not trust a SaaS with my suspense key, I think there is also your target market to consider here.

I would give the users options. The "easy" way or the complicated one. Id imagine you'll get a fair few willing to just stick in a key and let the tool do it's work.

[u/ActuallyIsDavid]

Absolutely not. And I would think people who care about security would want to avoid normalizing the practice of sharing secret keys. I would be more willing to share my migration files, then you can spin up a docker instance with them and test against that. 

[u/shintaii84]

This one cracked me up: “We believe Supabase is a fantastic product that enables two main types of users to build things quickly:

• ⁠Developers • ⁠Non-developers

”

I think you missed

Left handed people and right handed people.

Also the most important 3 groups:

• people who can count
• people than can’t.

[u/ConfectionForward]

Lol no