Guide · Supabase
Supabase says “RLS enabled no policy”. Why your app shows nothing, and the fix.
It means a table is locked: its rule is switched on, but nobody has been given permission to use it, so your app reads nothing from it. Your data is safe and still there. Supabase marks this as information, not an error. The fix is to add a rule saying who may read and change the table, never to switch the rule off.
What does “RLS enabled no policy” mean?
RLS (row level security) is the switch that makes a table check who is asking. A policy is a rule that says who is allowed in. With the switch on and no policy at all, the answer to everyone is no. Supabase’s own words: “no data can be read or written through the API.”
That is why it is the opposite of Supabase’s more serious warning, “RLS disabled in public”, where the switch is off and anyone can get in.
Why does Supabase return an empty array?
This is the same thing seen from inside your app. When a table has no policy, asking it for rows does not fail with an error. It answers with an empty list, an “empty array” in the words your AI tool will use, as though the table had nothing in it. The rows are all still there; your app is simply not allowed to see them. If a list in your app went blank with no error message, this is the first thing to check.
Why did this happen?
Almost always because someone switched the rule on and stopped there. Often that is the right first move: if you just fixed “RLS disabled in public”, this warning is the expected next step, and the table is now safer than it was. Tables made in Supabase’s own Table Editor also start with the switch on, so a new table can show this before anyone has written a rule for it.
Do not switch the rule off to make it work
Do not switch row level security off, and do not let your AI tool do it, even though it brings your data straight back. It brings it back for everyone: the table becomes readable and changeable by anyone who has your project’s address, which is the serious warning again. The same goes for putting the secret service role key in your app to get around the rule. Both make the symptom go away by opening the door.
How do I fix it?
1. See which tables it is
In your Supabase dashboard, open Advisors, then Security Advisor. Each table with this note is listed by name.
2. Decide who should get in, table by table
- Something about a person (profiles, orders, messages, bookings): only the signed in person it belongs to.
- Something on your public pages (products, a menu, blog posts): anyone may read, nobody else may change.
- Something only your own server uses (logs, settings): nobody through the app. For these, no policy is already right.
3. Ask the tool that built your app to add the rules
Paste this into Lovable, Bolt, Cursor or whichever tool you used:
Some tables in my Supabase database have row level security turned on but no policy, so my app cannot read them. Keep row level security turned on for every table. Add a policy to each one instead: signed in users can read and change only their own rows, and visitors who are not signed in can only read tables that are meant to be public, such as a product list. Do not turn row level security off and do not use the service role key in the browser to get around it. When you are done, list every table and the policy you gave it.
4. Or add them yourself in Supabase
In the SQL Editor, these are Supabase’s own examples. For a table everyone may read, with your table’s name in place of profiles:
create policy "Public profiles are visible to everyone."
on profiles for select
to anon
using ( true );For a table where each person may only see their own rows:
create policy "User can see their own profile only."
on profiles
for select using ( (select auth.uid()) = user_id );These only allow reading. Adding, changing and deleting each need a rule of their own, which is why step 3 is the easier route for most people.
5. Check you opened only what you meant to
Reload your app: the data should be back. Then check from the outside, the way a stranger would. Our free database check finds your app’s public key the way a visitor’s browser does and shows which tables a stranger can read, so you can see that the product list is open and the customer list is not.
GuardCue checks apps built with AI tools and explains what it finds in plain English, for the person who built it rather than for a developer. Check your database, free.