1. Guides
  2. Row-level security, and why your app needs it

Security

Row-level security, and why your app needs it

The setting that decides whether anyone with your app's public key can read every row in your database.

Sourced from vendor docs
Checked
20 Oct 2026
Read
2 min
Sources
2
How we check

If your app talks to Supabase straight from the browser, your database is reachable from the internet. Row-level security (RLS) is what stops one user reading another user's data. It's one of the first things to check before you launch.

What RLS does

RLS is a set of rules that live inside the database. Supabase describes each rule, called a policy, as working like a WHERE clause added to every query on that table. A policy can say "signed-in users can only read rows where the user_id is their own". The database applies it to every request, whatever the app's code asks for.

What happens without it

Without RLS, a table in an exposed schema is open to any role that has been granted access to it. That includes requests made with the public (publishable) key your app ships to every browser. Anyone who opens the browser tools can find that key and use it.

Once RLS is on, the opposite is true: no data comes back through the API with the public key until you add policies that allow it.

The secret key is different

Supabase also gives you a secret key. It uses a role that bypasses RLS, so it must only ever run on your server, never in the browser. If the secret key leaks, RLS doesn't protect you.

A first policy

This is Supabase's own example. It lets signed-in users read only their own profile:

```sql alter table profiles enable row level security;

create policy "Users can view their own profile." on profiles for select to authenticated using ( (select auth.uid()) = user_id ); ```

to authenticated means the rule only runs for signed-in users, so visitors who aren't signed in get nothing. using keeps only the rows whose user_id matches the person asking.

A quick check before launch

  1. Open the Supabase dashboard and run the Security Advisor. It flags tables with RLS turned off.
  2. Turn RLS on for every table your app reads from the browser.
  3. Add one policy per action you need (read, insert, update, delete), and nothing more.
  4. Sign in as a test user and try to read someone else's row. You should get nothing back.

Our pre-launch security pass walks through this alongside secret scanning and hosting settings.

Sources