RLS disabled in public - Database linter error

[autopaybyphone]

Hi there,

We suddenly received an email from Supabase Security Advisor, warning about tables in the public schema not having Row Level Security.

The doc says:

Tables in the public schema are accessible over Supabase APIs. If row level security (RLS) is not enabled on a public table, anyone with the project's URL can CREATE/READ/UPDATE/DELETE (CRUD) rows in the impacted table. Publicly exposing full CRUD to the internet is a critically unsafe configuration.

We tried to read about this, and feel like this is not totally accurate.

We don't use Supabase's API, we only use Supabase from our server. Thus our users query our server, which connects to the database through the database string. Thus we haven't broadcast the API key anywhere.

Do you confirm our understanding, that if we haven't published any API key, then it is safe to keep RLS disabled on the public schema?

If so, I think the doc should be updated.

In any case, would it be safe to remove public from the "exposed schemas"? That would probably remove the linter errors. But would it cause problems given our way of using the database?

Thanks in advance for the help!

[GaryAustin1]

If you never show your anon key in public or use it on a client then you can get by without RLS enabled. If you remove public from the API it should only impact PostgREST (REST clients) access to the db.

As far as feedback to Supabase, not sure they will see it here. An issue in supabase/splinter would be best approach.

[autopaybyphone]

Thanks a lot for the reply!

About removing public from the schemas exposed to the API, actually I realized that this might break. The database string that we use is the Supavisor one. We have to, because our network doesn't support IPv6.

Do you know if Supavisor goes through PostgREST? If so, do you confirm that removing public from the "exposed schemas" would break everything?

[GaryAustin1]

Supavisor does not involve PostgREST at all. It goes directly to the database. PostgREST is a REST API and the settings for schemas are just for it.

[autopaybyphone]

Awesome, thanks a lot! So to wrap up:

• given that we don't expose the API key anywhere and only connect to the database only from our server, it's safe to keep RLS disabled
• to remove these errors from the linter, it's safe to remove public from the "exposed schemas" in the API settings, connecting through Supavisor will still work

Did we get it right?

[GaryAustin1]

I'm not a fan of saying ignore best practices and not enable RLS. Flipping that switch seems easy and you don't need policies if you are access the database as Postgres user the direct database. But it is true if you never leak that key then your database can't be accessed thru the REST API.

I've never removed public from the API settings. But Supavisor does not use that setting so you will not impact Supavisor. I can't think of anything else that uses PostgREST (the database REST API) besides the dashboard health check, but I only tested you can turn it off (which might be a new feature) and it did not break that.

[autopaybyphone]

Thanks a lot once again for the swift and helpful reply!

With regards to best practices, it seems to us that removing public from the API exposed schemas would bring us to a best practice zone: in that setting, even if we leaked the API key, we would still be safe. Or is it that it is always recommended to have RLS enabled, even when one doesn't use an API-enabled service?

We are not super interested in RLS, because we prefer having unit tests on our API endpoints, which guarantee security. It seems more secure to us than relying on SQL statements, that might be forgotten when needing to be updated, or that might have mistakes not catchable by unit tests.

We'll open an issue regarding the docs.

Thanks again very much for the help!