FixLoop

Is my Supabase database public?

Guide · October 14, 2026

You shipped a Lovable app. The anon key is in the browser (it is supposed to be). The scary question is not "is the key exposed." It is: can a stranger read a table with that key and no login?

If Row Level Security is off on a table that still has grants to anon, the answer is yes. The Data API is a public database. This is a 5-minute check you can run on your own project.

Same model in the Row Level Security and Securing your API docs.

What "RLS off + anon key in the client" means

The anon key is a public JWT. Lovable (and Vite, Next, the rest) put it in env vars like VITE_SUPABASE_ANON_KEY or NEXT_PUBLIC_SUPABASE_ANON_KEY so the browser can talk to Supabase. Anyone who loads your app can copy it. That part is normal.

Postgres then decides what that key is allowed to do:

1. Grants decide whether anon can SELECT / INSERT / UPDATE / DELETE the table at all.
2. RLS decides which rows survive that grant.

RLS off means step 2 never runs. If anon also has a grant (the old default on public tables), every row is reachable from the REST endpoint. Emails, orders, chat messages, whatever you stored.

A policy of using (true) is the same shape of hole with RLS "on." The dashboard badge looks fine. The table is still public.

The 5-minute check

Do this on your project, from a private window so you are not accidentally sending a user session.

1. Copy the project URL and anon key

Easiest path: open the live app, DevTools → Network, filter rest/v1 or supabase.co. Click a request.

• Host looks like abcdefghij.supabase.co.
• Path looks like /rest/v1/profiles (that last segment is the table name).
• Request headers: apikey and Authorization: Bearer …. For signed-out traffic those two values are the anon key.

No traffic yet? Check Lovable env / a local .env for SUPABASE_URL and the anon key. Do not use the service_role key. That one bypasses RLS and must never ship to the client.

2. Read a table with no login

Pick a table the app actually uses. Names from the network tab beat guessing. Common Lovable ones: profiles, users, messages, todos, orders.

curl "https://YOUR_PROJECT.supabase.co/rest/v1/YOUR_TABLE?select=*&limit=5" \
  -H "apikey: YOUR_ANON_KEY" \
  -H "Authorization: Bearer YOUR_ANON_KEY"

Same thing from the browser console on any blank tab:

const res = await fetch(
  "https://YOUR_PROJECT.supabase.co/rest/v1/YOUR_TABLE?select=*&limit=5",
  {
    headers: {
      apikey: "YOUR_ANON_KEY",
      Authorization: "Bearer YOUR_ANON_KEY",
    },
  }
);
console.log(res.status, await res.json());

No cookies. No supabase.auth.getSession(). If this returns user data, a stranger can do it too.

3. Read the result

• 200 and an array of rows. anon can read the table. If you see emails, names, contents, payment fields, treat it as public. RLS is off, or a policy allows anonymous SELECT.
• 200 and []. The Data API can see the table (there is a SELECT grant) but no rows passed RLS, or the table is empty. Retry a table you know has data. If the signed-in app shows rows and anon still gets [], signed-out visitors are probably blocked. That is the usual healthy case.
• 401. Missing, truncated, or invalid key. Fix the header and retry. A 401 here does not mean the table is private.
• 403 / 42501 / permission denied for table. anon has no grant, so the Data API never reaches RLS. The table is not exposed to that role. After October 30, 2026 this shows up a lot on new tables. Different problem: the grants change guide.
• 404 / PGRST205. Wrong table name, or it is not in the API schema cache. Use the name from the network tab.

Stop after a handful of rows. If you see other people's data, turn RLS on before you paste anything into a chat window.

The safe fix

Turn RLS on, then add policies that filter by auth.uid(). Grants stay least-privilege. Do not "fix" an open table by granting more.

alter table public.your_table enable row level security;

create policy "select own rows"
on public.your_table
for select
to authenticated
using (auth.uid() = user_id);

create policy "insert own rows"
on public.your_table
for insert
to authenticated
with check (auth.uid() = user_id);

create policy "update own rows"
on public.your_table
for update
to authenticated
using (auth.uid() = user_id)
with check (auth.uid() = user_id);

grant select, insert, update, delete on table public.your_table to authenticated;
grant select, insert, update, delete on table public.your_table to service_role;

Swap user_id for whatever column stores the owner. After RLS is on with no matching policy, even you get [] until the policy is right. That is safer than open.

In Lovable, put the same rules in the project instructions so the next migration does not recreate the hole: enable RLS, policies using auth.uid(), no GRANT ALL to anon.

Quick checklist

• Anon key in the client is expected. RLS off (or using (true)) is the actual problem.
• Copy the key from a signed-out Network request, not from a logged-in session.
• Hit /rest/v1/<table>?select=*&limit=5 with apikey + Authorization: Bearer.
• Rows with private fields: enable RLS and lock policies to auth.uid() before you do anything else.
• [] on a table that has data: usually RLS is on for anon. Confirm on more than one table. Logged-in writes that "save" and revert are the silent update guide.
• 401: bad key. 42501: no grant (see the Oct 30 grants guide).
• Never GRANT ALL to anon, and never grant to anon with RLS off.

Questions