Guide Supabase

Supabase emailed "Table publicly accessible": what it means and what to do before you launch

By the PatchAndShip team Last verified:

Short answer

The email is about a table in your public schema with access rules (Row Level Security, or RLS) switched off. Supabase's Security Advisor calls that ERROR "Table publicly accessible": anyone with your project URL can read, edit and delete data in that table. It does not mean someone already stole your data. It means the door is open until you close it.

Where you see the same warning

Open your Supabase project, go to Advisors, then Security Advisor. Look for the ERROR whose Summary is "Table publicly accessible" (lint 0013_rls_disabled_in_public). The finding names the tables that are reachable through the API without RLS.

Supabase says organization owners receive weekly security emails summarizing Advisor findings. An older product post said project owners get those weekly emails. The Advisors docs page itself does not spell out the email cadence, so also check Security Advisor in the dashboard rather than waiting on an inbox message.

First fix: turn RLS on and add policies in the same change

For each table the ERROR lists:

  1. Turn on Row Level Security for that table.
  2. In the same change, add policies that say who may read and change which rows.

Once RLS is on, no data is accessible through the API when using a publishable (anon) key until you create policies. The Advisor resolve note for this lint says the same: after enabling RLS you will not be able to use the anon role to read or write data to the table via Supabase APIs until you create row level security policies. Turning the switch alone, with no policies yet, can blank your app for normal users.

This page is the email moment: what the warning means and what to do next. For a step-by-step fix of those access rules (RLS) in a Lovable app, use the related guide on fixing Supabase RLS rather than repeating that how-to here.

After ERROR 0013 clears

Clearing "Table publicly accessible" is step one, not the whole pre-launch check.

Still open Security Advisor and look for WARN 0024_permissive_rls_policy, Summary "Security policy allows unrestricted access." That WARN flags policies that use always-true conditions such as USING (true) or WITH CHECK (true), which defeat the point of having RLS on. Do not treat Advisor as quiet or green while those always-true policies still exist. Advisor can surface them as a WARN; it does not skip always-true read policies.

Even when WARN 0024 is quiet, Advisor is a start, not proof that live access behaves the way you expect. Run the signed-out test and the two-account test described in the related pre-launch and leak guides. Those checks ask: can someone who is not signed in read private rows, and can user B see user A's private rows.

What you can DIY vs when to get a second look

You can turn RLS on, add a first set of policies, re-run Security Advisor, and try the signed-out and two-account tests yourself.

Stop guessing if you cannot tell, in plain words, whether each policy means "each user only their own rows" or "everyone." That is the natural handoff to a read-only second look before you launch.

Want a second pair of eyes?

Clearing the email is step one. If you are not sure the new rules only let each user see their own data, the $49 Database Check is a read-only second look: you run our script and send the results. No passwords, no keys, no login to your account. We change nothing. AI agents run the checks and a human engineer reviews and approves every report. Not a penetration test, a security guarantee or a compliance certification.

See plans and prices

Sources