What is Row Level Security (RLS)?

The core idea

Row Level Security (RLS) is a Postgres feature, used by both Lovable Cloud and Supabase, that filters rows rather than whole tables. Instead of an app deciding what data to show, the database itself checks a policy on every query and only returns or accepts rows that pass it.

This matters because your front-end code is never trustworthy on its own — anyone can open dev tools and call your database's API directly. RLS is the actual security boundary; the UI is not.

How it works

• RLS is enabled per table.
• Once enabled, all access is denied by default unless a policy explicitly allows it.
• A policy is a rule like "authenticated users can SELECT rows where user_id = auth.uid()".
• You can have separate policies for SELECT, INSERT, UPDATE and DELETE, and different policies per role (anonymous vs authenticated vs a custom role).

A simple example

create policy "Users see their own orders"
on orders for select
to authenticated
using (auth.uid() = user_id);

This says: authenticated users can read rows from orders, but only ones where the row's user_id matches their own ID.

Why roles need their own table

For anything role-based (admin, moderator, etc.), store roles in a separate user_roles table rather than a column on profiles. A role column on a user's own row can, depending on your policies, end up editable by the user themselves — a serious privilege-escalation risk. A separate table with its own RLS lets you control who can grant or read roles independently.

What usually goes wrong

• Assuming the app's UI hiding a button is enough protection — it isn't, since the underlying query is still reachable.
• Turning RLS off to unblock development and forgetting to turn it back on before publishing.
• Writing a policy that's too broad (using (true)) just to stop errors, which defeats the purpose.

For related setup questions see /questions/do-i-need-rls-on-my-lovable-app and /questions/how-do-i-fix-rls-errors.