Storing sensitive data in Supabase public schema?

Question

Supabase uses a public schema in Postgres that exposes your schema to their REST API and GraphQL endpoints.

I understand that RLS policies can be set so that, for instance, a user can only see their own data and no one elses.

But let's say sensitive information is stored in a public schema's table as well, something like encrypted third party refresh/access tokens or the like. For example, let's just say a table called tokens. With an RLS policy, the user can only access their own tokens, that makes sense.

But the schema is still public, meaning, malicious actors now know what to look for in terms of the shape of the data/database design.

Am I being paranoid that this schema is public and "not obscure", or is this lack of "security through obscurity" not a problem since the data itself is protected by RLS?

Thanks!

Answer 1

I think you have several options...

1. Add views to your public table so that the user can only 'see' a subset of the columns in your table. This makes your table definition a little more complicated but seems like a good solution otherwise.

2. Put the sensitive data somewhere else. I don't think you can stick it in 'auth.users', so you would need to have another table that is not exposed to the user and has a 1-to-1 relationship with the public table in question. That would have a performance penalty, of course, so could be a bad option depending on how frequently you need to access this private data.

3. Use encryption - perhaps Postgres' built-in encryption functions - on that one field.

I would suggest that #1 is the most 'Supabase' native solution. On the other hand, I'm one of those who think of RLS as just one way of using Supabase - it is certainly not a requirement so I guess option #4 would be that RLS is not the right solution for that table or that project.