What are some rules of thumb when choosing between RLS and security barrier views? #3424
-
Hello, As far as I understand, there are 2 main ways to secure data in PostgreSQL:
I understand that the 2 can often be combined so that RLS provides access control on the row axis (i.e. it only allows certain rows to be visible) while the view provides access control on the column axis (i.e. it only allows certain columns to be visible). However, it seems to me that as long as the view is marked with security_barrier, it can also provide access control on the row axis by using an appropriate WHERE clause (and possibly a CHECK OPTION for updates/inserts). In Supabase's case, I assume that the WHERE clause of such views can take advantage of the predefined auth.uid() function, e.g.:
With that in mind, what are some rules of thumb about when to use RLS and when to use security barrier views? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
Hey @chipilov,
Security barrier views predate policies, they were used at a certain point to implement row-level security. See this blog post for more details. With the security barrier approach you basically have to recreate the RLS functionality manually in your VIEWs. It works, but it's more complicated. With RLS you can be fine-grained about statement type(INSERT/UPDATE/DELETE) and the postgres role for which the policy is applied.
Note that you can also combine regular VIEWs with RLS, see #1501. That would give you the same ability to hide a column.
There's also table-level/column-level security through GRANTs, you could
I'd recommend sticking to RLS and combining it with regular views as mentioned above. |
Beta Was this translation helpful? Give feedback.
Hey @chipilov,
Security barrier views predate policies, they were used at a certain point to implement row-level security. See this blog post for more details.
With the security barrier approach you basically have to recreate the RLS functionality manually in your VIEWs. It works, but it's more complicated.
With RLS you can be fine-grained about statement type(INSERT/UPDATE/DELETE) and the postgres role for which the policy is applied.
Note that you can also combine re…