← All guides

Supabase Row Level Security (RLS) explained for non-coders

Updated 22 October 2026 · 6 min read

Short answer: Row Level Security is a set of rules inside your database that decides which rows each user can see or change. If it's off on a table, anyone with your app's public key can read and edit every row. Turn it on for every table and add 'owner only' policies.

What is RLS, in plain English?

Think of your database as a filing cabinet that sits on the public internet. Your app's public key opens the cabinet. RLS is the rule on each drawer that says "you can only see your own folders". Supabase's docs warn: a table "without RLS is readable and writable by any role with a grant on it". (Supabase RLS docs)

Why do AI-built apps get RLS wrong?

  • The AI builds the feature first and the security rules second, or never.
  • It writes a policy like using (true) to "make the error go away", which opens the table to everyone.
  • It checks permissions in the browser (hiding a button) instead of in the database.

The researcher behind CVE-2025-48757 found Lovable's early scanner only checked that a policy existed, not whether it was correct. (source) One reported case exposed 18,697 student records because of an inverted authentication check. (source)

How do I fix RLS without code?

Step 1: turn it on everywhere.

Go through every table in my Supabase database. Turn on Row Level Security for each one. For tables with user data, add policies so a signed-in user can only select, insert, update and delete rows where user_id = auth.uid(). Remove any policy that uses `true` for everyone. Don't change the app's features. When you're done, list every table with its policies in a simple table.

Step 2: shared or public tables. For things like blog posts or products that everyone should see:

For my public tables (list them), allow everyone to SELECT, but only allow admins (users whose role in the profiles table is 'admin') to INSERT, UPDATE or DELETE. Enforce this with RLS policies, not frontend checks.

Step 3: test it.

Write me a short checklist to test my RLS: sign in as user A, try to read and edit user B's rows, and try the same while signed out. Tell me what result I should see for each table.

How do I know it worked?

Open Supabase → Advisors → Security Advisor. It should show no RLS errors. Then run a free Vibe Check and check our pre-launch checklist.

Not sure if your app has this problem?

Run a free Vibe Check. It takes about 10 seconds and only reads public pages.

Run free Vibe Check

FAQ

What does using (true) mean?

It means 'allow everyone'. On a table with private data, it makes RLS useless.

Does RLS slow my app down?

Simple owner-only policies have little impact for typical small apps; index the user_id column if a table grows large.