How does row-level security work in UI Bakery?

Help & Support 💻
1

Hi UI Bakery team,

I’m building applications in UI Bakery connected to a Supabase database, and I want to make sure I properly secure data access for different users (for example, freelancers who should only see their own data).

From the UI Bakery documentation, I see an example ( Implementing row-level security | UI Bakery Docs ) where row-level access is implemented by filtering queries using {{ user.email }}, like this:

SELECT p.*
FROM products p
JOIN user_categories uc ON p.category_id = uc.category_id
WHERE uc.user_email = {{ user.email }}

I understand that {{ user.email }} cannot be changed from the client side, which sounds safe.
However, I’m unsure how this compares to database-level security.

My main questions are:

  1. Does this kind of filtering in UI Bakery fully prevent users from accessing other rows, or does it only control what the UI shows?

  2. Since UI Bakery connects to the database with its own credentials, could users still see more data (for example via network inspection) if a query is not properly restricted?

  3. Does it make sense (and is it supported) to use Supabase Row Level Security (RLS) together with UI Bakery?

  4. If Supabase RLS is enabled, will UI Bakery continue to work normally, or do queries need to be adapted?

  5. What is the recommended best-practice setup to ensure users can never access data they are not supposed to see?

For context: I’m still a beginner when it comes to database security and RLS, and I’m trying to understand the correct and safe architecture rather than relying on assumptions.

Thanks in advance for any clarification!

2

At the moment, UI Bakery does not natively support Supabase RLS, because UI Bakery connects to Supabase using its own database credentials and does not pass the end-user auth context (auth.uid()) to the database.

Given that, here’s how to think about security:

1) Filtering with {{ user.email }}
This filtering is applied server-side, not in the browser, so users cannot change it or bypass it via network inspection. It’s safe per query.

However, it is still application-level security:

  • Every query/action must include the restriction

  • A missing filter in any action can expose extra data

2) Can users access more data anyway?
Users can’t run arbitrary SQL, but they can call any action the app exposes. If an action returns unrestricted data, they can receive it legitimately.

3) What’s the recommended setup without Supabase RLS?
Best practice with UI Bakery today is:

  • Enforce row-level restrictions in every query using {{ user.email }}

  • Lock down page and action permissions so users can only trigger allowed actions

  • Avoid generic queries like SELECT * FROM table

  • Treat query reviews as a security checklist item

Without database-level RLS, security depends on consistent server-side filtering + strict app permissions. It’s safe when done correctly.

1 Like