Guide · 2 min read · Updated November 8, 2026

Supabase row level security (RLS), explained simply

If your app uses Supabase, row level security is the single most important setting to get right. Here's what it is and how to check yours, without the jargon.

What it is

Your Supabase database comes with a public key that lives inside your website. That's normal: it's how your site talks to the database. Row level security (RLS) is the lock that decides what that public key is allowed to do, table by table and row by row.

Without RLS, the public key can read every row in the table. With RLS on and a good rule (a policy), each person only sees their own data.

Why AI-built apps often miss it

AI tools create tables quickly so your app works right away. Turning on RLS and writing policies is a separate step, and it's easy to skip when everything already seems to work.

How to turn it on

For each table, ask your AI tool, or run this in the Supabase SQL editor (replace orders with your table name):

alter table orders enable row level security;

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

This turns on the lock, then lets a logged-in person read only the rows where user_id is their own ID. Add similar policies for adding, changing and deleting rows.

The open-door mistake

A policy that says using (true) lets everyone through, so RLS looks on but protects nothing. Why it matters.

How to check yours

• Run npx sigship in your project. It finds tables in your migration files without RLS, and policies that let anyone write.
• Open Supabase's security advisor in your dashboard, which checks the live database, including settings made there.

Questions

More guides

• Vibe coding security checklist
• Check a Lovable, Bolt, Replit or v0 app
• Leaked an API key? What to do now
• Jargon, explained