Answers / Database security

What is row level security and do I need it?

Matt Turley, Continuum. Updated November 5, 2026.

What the rule does in plain words, when you need it, and the mistakes AI tools make writing it.

The short answer

What is row level security and do I need it?

Row level security is a rule on a database table that decides which rows each user may read or change. If your app uses Supabase from the browser and holds more than one person’s data, you need it on every table. Without it, the public key can read what you meant to protect.

What it does, in plain words

A table of orders holds every customer’s orders. Row level security adds a rule such as: a signed-in user may see only rows where the owner is themselves. The database enforces it on every request, so even a hand-made request from outside the app cannot get around it.

It matters most in setups where the browser talks to the database directly, which is how many AI-built apps on Supabase work. There the rule is not an extra layer; it is the lock. See Supabase’s own explanation.

Do you need it?

  • Yes, if the app holds data belonging to different people and the browser reaches the database.
  • Yes, for any table that a stranger should never read: users, orders, messages, bookings, documents.
  • You may not need row rules for a table that is public on purpose, such as a product list, though you still control who can write to it.
  • If a server you wrote sits between the browser and the database and checks everything, the database rules are a second safety net and still worth having.

Mistakes AI tools make with it

The most common is leaving it off, because everything works without it. The next is switching it on, seeing the app go blank because no rules exist, and adding a rule that simply allows everyone, which reopens the table while looking fixed. Another is using the service role key from the browser, which skips the rules altogether.

In our October scan, 31 of 177 Supabase-backed apps built with Lovable, Bolt or base44 had at least one table answering with no login. The dataset is public.

How to check yours

List your tables, confirm the rules are on for each, read every policy in plain words, and test with a request that carries no login. The Supabase security review does this with a written proof for each finding, and the free production-readiness check tests rule enforcement on a live URL.

Want one concrete finding on your own app?

Paste your live app URL and your email. A short automated check runs three public-security spot-checks and sends back one specific finding and what to do about it. It is free, and it is a preview, never a clean bill of health.

Run the free is-it-safe-to-ship check. Or book a call and talk it through.

Book a call →See all services and prices →
FAQ

Straight answers

Is row level security the same as login?
No. Login proves who someone is. Row level security decides what that person, or a stranger, may see once they are asking. An app can have working login and still leave tables open.
What happens if I switch it on and write no rules?
Ordinary requests are blocked, which is safe but usually makes the app look empty. Write rules for each table that say who may read and who may change which rows.
Does row level security slow my app down?
Rules add a small check to each request. For ordinary apps it is rarely noticeable, and a badly written rule is easier to fix than a data leak.
Do I need it if I use a different database?
The idea applies anywhere the database can be reached by anyone other than your own server. Where only your server talks to the database, you enforce the same rule in your server code instead.
Keep reading
Run the free is-it-safe-to-ship checkFree. One finding on your own app.Is my Supabase secure?A practical checklist before you launch.Can anyone read my Supabase data without logging in?Why the public key is fine and the table rules are the lock.Supabase security reviewRow level security, keys, storage and auth, with a proof for each finding.Is my Supabase app production ready?A free check you can run on a live URL.The AI-built app exposure scanMethod, denominators and the full dataset.Is it safe to put API keys in my frontend code?Which keys may be public and which must never be.
Sources
  1. 1. Supabase: Row Level Security, Supabase: Used for what row level security is: policies on a table that decide which rows each signed-in user can read or change.
  2. 2. Supabase: API keys and the service role, Supabase: Used for the point that the service role key bypasses row level security and belongs on a server only, never in the browser.
  3. 3. AI-built app database exposure scan, October 2026, Continuum, October 2026: Used for the figures on how many scanned Lovable, Bolt and base44 apps on Supabase had a table readable with no login. Method, denominators and the full dataset are on the page.
What is row level security and do I need it? | Continuum